TiddlyWeb update
chris...@gmail.com
I wanted to give a bit of an update on the status of TiddlyWeb, ask a
few questions, point out some future directions, invite some help and
the like.
The first question, before I lose the only half interested in the
noise below: Do people mind TiddlyWeb discussion happening on
TiddlyWikiDev, or would they prefer there be a TiddlyWebDev group of
its own.
On to the updates:
* TiddlyWeb now tweets on twitter as 'tiddlyweb', follow, if you are
interested, by going to http://twitter.com/tiddlyweb
* I've added an optional store for the google data system under
Google's AppEngine, and provided a simple server to make it go. See
the googleappengine directory in the codebase[1].
* That GAE code is up and running at http://tiddlyweb.appspot.com with
much the same content as is on the http://peermore.com:8080/ site. Try
http://tiddlyweb.appspot.com/recipes/wiki/tiddlers/TiddlyWeb
* Very simple support for user authorization and authentication is
stubbed into place with working models of Basic Auth and a simple form
that creates a cookie. Neither of these is secure yet, they just show
it can work.
* There is an optional serialization for producing Atom feeds of
filtered lists of tiddlers and single tiddlers. See the atom directory
in the codebase[2].
In the past week or so I've moved from trying to get the basic
architecture working, to taking advantage of that architecture and I
can say that the ease with which I added support for GoogleAppEngine
(it took an evening, most of that was fighting with memcache support)
suggests that the architecture is going to work out nicely.
It is very likely that I'm going to take a break for the month of
August and then give a demo of TiddlyWeb at WikiSym 08 in September.
That means it would be great if I could get TiddlyWeb to the state of
a reasonable beta (useful to other people than me) by the end of
July. For those who are interested or have been following along I'd
very much appreciate:
* Your comments on what's needed, what's wrong, what's great, etc.
* Any help you might wish to provide.
I know from comments people have made that at the moment the system is
a bit unapproachable. As this is entirely contrary to one of the
goals, I'd love to hear from people about what it needs to make it
approachable. Other areas of concern or interest are listed below.
Things on the plate:
* Get user authentication working properly.
* Work with a few "verticals" to get them working in a TiddlyWeb
setting.
* Refactor the code for cleanliness.
* Document the code.
* Improve the test/importer.py script so it is a useful tool.
* Expose user management functionality.
* Resolve questions of administrative permissions on bags, recipes and
the entire server.
Things on the horizon:
* Improve the Atom code to give more metadata.
* Update the GAE code to support users and auth mgt by GoogleAuth.
* A TiddlyWebScopePlugin that allows a TiddlyWiki to browse an
arbitrary TiddlyWeb and select content, create and manipulate recipes
and bags.
* OpenID support in the auth sytem.
* A store that can talk to the plugin library that FND is working on.
* Support Atom as an incoming serialization not just outgoing (thus,
support the Atom Publishing Protocol).
And just so I'm noting it somewhere, as far as I can deduce, things
like MarkupPreHead are only activated when a TiddlyWiki is saved, not
when it first starts up, is this true? Wanted to use it to
automagically set the link to an Atom feed on a just downloaded
TiddlyWiki.
[1] http://trac.tiddlywiki.org/browser/Trunk/contributors/ChrisDent/experimental/TiddlyWeb/googleappengine
[2] http://trac.tiddlywiki.org/browser/Trunk/contributors/ChrisDent/experimental/TiddlyWeb/atom
mcmanu...@gmail.com
I have been trying to get some of the ccTiddly plugins into a state
where there can be used in TiddlyWeb. They still need some work and
will not be perfect for July but if you can give me a URI to post a
username and password (sha1 hashed at the moment) we should be able to
make a start.
Currently ccTiddly is not using the adapter framework but that is due
in ccTiddly 1.7. I guess there will be differences but we should be
able to achieve a certain level of reuse - and also start us thinking
about future "integration".
Do you plan to have a page refresh when the user logs in? Or will the
tiddlers be loaded without a refresh?
We can actually make it work either way but it helps to know.
I have also been playing with some Selenium testing for TiddlyWiki/
ccTiddly/TiddlyWeb.
If all goes to plan we should be able to use the login test across
both systems.
I suggest you avoid creating a TiddlyWeb group, I sometimes feel the
ccTiddly misses out on the extensive knowledge in this group. I would
be interested to hear the views of more regular contributors though.
Cheers
Simon
> Hi Everyone,
>
> I wanted to give a bit of an update on the status of TiddlyWeb, ask a
> few questions, point out some future directions, invite some help and
> the like.
>
> The first question, before I lose the only half interested in the
> noise below: Do people mind TiddlyWeb discussion happening on
> TiddlyWikiDev, or would they prefer there be a TiddlyWebDev group of
> its own.
>
> On to the updates:
>
> * TiddlyWeb now tweets on twitter as 'tiddlyweb', follow, if you are
> * I've added an optional store for the google data system under
> Google's AppEngine, and provided a simple server to make it go. See
> the googleappengine directory in the codebase[1].
>
> * That GAE code is up and running athttp://tiddlyweb.appspot.comwith
> [2]http://trac.tiddlywiki.org/browser/Trunk/contributors/ChrisDent/exper...
Xavier Verges
> noise below: Do people mind TiddlyWeb discussion happening on
> TiddlyWikiDev, or would they prefer there be a TiddlyWebDev group of
> its own.
-Xv
FND
>> or would they prefer there be a TiddlyWebDev group of its own.
>
> I'm happy about them happening here.
I guess moving TiddlyWeb discussions to a separate group would not be
helpful at this point.
If the volume of strictly TiddlyWeb-related postings increases
significantly, maybe then a dedicated group could be set up.
-- F.
FND
> architecture working, to taking advantage of that architecture and I
That's great!
> * Your comments on what's needed, what's wrong, what's great, etc.
I think instructions for getting started (installation, setup) would be
very helpful.
You've done a great job of documenting the goals and progress on the
community wiki* - but end-users don't quite know where to begin...
Maybe if you walk me through it, I could create a quick guide.
> * Any help you might wish to provide.
Do you have a list of specific tasks that need doing?
I'm planning to start work on the plugin library store early next week,
and hope that will also lead to contributions to the TiddlyWeb core.
> And just so I'm noting it somewhere, as far as I can deduce, things
> like MarkupPreHead are only activated when a TiddlyWiki is saved, not
> when it first starts up, is this true?
Not entirely sure what you mean by "activated" here.
IIRC, every time the TiddlyWiki document is saved, all the markup blocks
are updated with the respective tiddler contents - saveMain() calls
updateOriginal() calls updateMarkupBlock().
-- F.
chris...@gmail.com
On Jun 21, 9:50 am, FND <F...@gmx.net> wrote:
> > * Your comments on what's needed, what's wrong, what's great, etc.
>
> I think instructions for getting started (installation, setup) would be
> very helpful.
> You've done a great job of documenting the goals and progress on the
> community wiki* - but end-users don't quite know where to begin...
> Maybe if you walk me through it, I could create a quick guide.
* For reasons I don't understand, the community wiki is completely not
on my radar. I need to fix that behavior.
* In the TiddlyWeb case I don't have a good description of definition
of the end-user: Who they are? What they want to do? So writing about
that is a struggle. I'm good at answering questions so perhaps we can
start there. A question led to this:
http://peermore.com:8080/recipes/AutoTiddlyWeb/tiddlers/WhatIsTiddlyWeb
So in a sense this thread is an attempt to get some sense of who the
end-user is.
> > * Any help you might wish to provide.
>
> Do you have a list of specific tasks that need doing?
> I'm planning to start work on the plugin library store early next week,
> and hope that will also lead to contributions to the TiddlyWeb core.
that more detailed if that's useful?
> > And just so I'm noting it somewhere, as far as I can deduce, things
> > like MarkupPreHead are only activated when a TiddlyWiki is saved, not
> > when it first starts up, is this true?
>
> Not entirely sure what you mean by "activated" here.
> IIRC, every time the TiddlyWiki document is saved, all the markup blocks
> are updated with the respective tiddler contents - saveMain() calls
> updateOriginal() calls updateMarkupBlock().
saved, so updateOriginal() is not called, os updateMarkupBlock() is
never called to set the blocks: the blocks don't get activated.
chris...@gmail.com
overview:
http://peermore.com:8080/recipes/AutoTiddlyWeb/tiddlers/TODO
FND
> on my radar. I need to fix that behavior.
You're not the only one - we could all do better...
> In the TiddlyWeb case I don't have a good description of definition
> of the end-user: Who they are? What they want to do?
I see two main types of users here:
* individuals requiring ubiquitous access to their document(s)
* teams/organizations generating and sharing information
At the moment, individuals typically use the UploadPlugin (e.g. on
Tiddlyspot), but might also use an FTP or WebDAV directory.
Teams probably prefer ccTiddly, but some opt for a network share or
even Subversion (or some other VCS).
More options are listed on the community wiki:
http://www.tiddlywiki.org/wiki/Server-Side_Solutions
Both groups probably want to be able to check out a standalone version,
modify it and push the changes back to the server later on.
When not using a hosted solution, the server should be easy to install
and configure.
Teams require the full range of multi-user collaboration features;
revision control (including diff'ing), access control, notification (via
RSS and/or e-mail) etc.
There are other uses as well - e.g. TiddlyWiki as a CMS for editors to
generate a regular website (static HTML), or TiddlyWiki as a blog with a
two-tiered authorization system (full write access vs. commenting).
Since collaboration is TW's weak spot at the moment, we should focus on
the multi-user aspects (individuals' needs will automatically be covered
then anyway).
These are rather obvious observations, of course - but maybe something
we can build upon and derive requirements from.
> There are the things mentioned in the start of this thread. I can make
> that more detailed if that's useful?
While I do have an immediate task to work on (the plugin library store),
I wonder whether there's something for other potential developers to get
started - some sort of quick hack to get hooked (that's the way it
usually works with TiddlyWiki).
Maybe OpenID support will get some geek interested...
We should also be realistic though; most people won't become actively
involved until they're actually using the system and feel like tweaking
something (itch-scratching).
(I'm also not sure how many Pythonistas there are in the TiddlyVerse,
but that's a different issue.)
> When a wiki is pulled down from a TiddlyWeb server it never gets
> saved, so updateOriginal() is not called, os updateMarkupBlock() is
> never called to set the blocks: the blocks don't get activated.
You should ping Jeremy and Martin about this (maybe start a dedicated
thread so this issue doesn't get buried here).
-- F.
Jeremy Ruston
>> > like MarkupPreHead are only activated when a TiddlyWiki is saved, not
>> > when it first starts up, is this true?
>>
>> Not entirely sure what you mean by "activated" here.
>> IIRC, every time the TiddlyWiki document is saved, all the markup blocks
>> are updated with the respective tiddler contents - saveMain() calls
>> updateOriginal() calls updateMarkupBlock().
>
> When a wiki is pulled down from a TiddlyWeb server it never gets
> saved, so updateOriginal() is not called, os updateMarkupBlock() is
> never called to set the blocks: the blocks don't get activated.
That's correct, when you save changes, the various
MarkupPre/Head/Post/Body tiddlers are spliced into the appropriate
places in the source file.
The current version of cook, I believe, automagically does the
equivalent thing (ie looks for the Markup* tiddlers and splices them
into the template at the appropriate points). I guess you can do the
same thing in TiddlyWeb? It suggests that you'll need a more
sophisticated template substitution approach; it would be cool if you
could use the same templates that cook uses...
In a TiddlyWeb world where content is being merged from multiple
sources, I think the Markup* tiddler approach is probably too
restrictive because it only allows for one of each markup tiddler. An
alternative approach might be to use tags instead. For instance, any
tiddlers tagged "markupPreHead" might be concatenated together and
inserted into the template en masse. Further, we might allow for an
optional 'ordering index' on the end of the tag, so that a tiddler
tagged "markupPreHead.100" would be inserted before a tiddler tagged
"markupPreHead.200".
Cheers
Jeremy
--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com
FND
I don't see server-side full-text search mentioned there - is that still
on the agenda (it's highly relevant for the plugin library, so I might
even try to look into this myself if you give me some pointers).
-- F.
Martin Budden
so by treating them as special cases. (Indeed a design philosophy of
cook is that it should have as little specialist knowledge of
tiddlywiki as possible. As far as possible it is a file merger, that
is it takes a set of input files (defined by a recipe) and puts them
in specific parts of a template, again defined by the recipe. The
major exception to this is that cook and ginsu understand the <div>,
.tiddler and .js formats of tiddlers, but cook and ginsu don't have a
concept of a tiddlywiki as such).
So to include a shadow tiddler in a markup position you use the
appropriate recipe directive, see (eg)
http://svn.tiddlywiki.org/Trunk/core/shadows/split.recipe
The first two lines are:
prehead: MarkupPreHead.tiddler
shadow: MarkupPreHead.tiddler
which instructs cook to put the content in the prehead and shadow
tiddlers part of the template file. This allows more than one tiddler
to go into the prehead section of the tiddlywiki if required. It also
allows content to go in the prehead section without having to be in a
shadow tiddler.
The tiddlywiki template file is at:
http://svn.tiddlywiki.org/Trunk/core/html/tiddlywiki.template.html
It is a valid html file (so can be parsed by html tools). The prehead
(and other sections) of the file are defined by html comments, eg:
<!--@@prehead@@-->
when cook cooks it replaces these markers with anything in the recipe
file that is specified to be inserted at these markers.
I had sort of assumed that TiddlyWeb would use the same template file
(to ensure compatibility with TiddlyWiki) when it generates TiddlyWiki
files. Is this the case?
Martin
2008/6/22 Jeremy Ruston <jeremy...@gmail.com>:
chris...@gmail.com
On Jul 1, 11:48 am, "Martin Budden" <mjbud...@gmail.com> wrote:
> I had sort of assumed that TiddlyWeb would use the same template file
> (to ensure compatibility with TiddlyWiki) when it generates TiddlyWiki
> files. Is this the case?
When I was first putting together the "squish these tiddlers into a
TiddlyWiki" aspect of TiddlyWeb I went for the simplest thing that
could possibly work, which at that time was:
* get and store http://tiddlywiki.com/empty.html
* split it on '</div>\n<!--POST-STOREAREA-->\n' into A and B
* output A + [div for each tiddler] + <split string> + B
I did it this way, in part, because I imagined a future where
empty.html was not stored locally but was automatically loaded over
HTTP as required (and cached locally using a caching HTTP library).
This would mean that the server was always serving the blessed empty
TiddlyWiki. I also did it this way because I wanted to preserve a
(perhaps misguided) notion that a TiddlyWiki is a frame around a set
of tiddlers and the tiddlers can make magic happen, without special
manipulation of the html file. In other words, I didn't want to cook,
I wanted to serialize, and let TiddlyWiki do its own magic, clientside
(that seems in the TiddlyWiki spirit).
This has worked really well until stumbling across the fact that
updateOriginal doesn't happen onload, but only on saveMain.
I can add some smarts to the wiki serialization in TiddlyWeb, so it
process variables in a template file, turning the serialization into a
version of cook, but I have to say, meh, I don't like it, for what I
guess are lame aesthetic reasons.
Is it possible for the MarkupPreHead and associated tiddlers to be
activated post load or is their functionality uniquely different such
that they won't work in the DOM properly unless they are present from
the start?
Generally speaking I want TiddlyWeb to be as stupid as possible and as
special case free as possible. At core it is a data store. My gut
reaction to this particular situation is that if TiddlyWiki is unable
to cope properly with some tiddlers that TiddlyWeb serves, then that
is a problem that needs to be solved (eventually) in TiddlyWiki,
because all TiddlyWeb does (at base) is serve tiddlers.
Thoughts?
FND
> activated post load or is their functionality uniquely different such
> that they won't work in the DOM properly unless they are present from
> the start?
I generally agree with the notion that TiddlyWeb should try to avoid any
unnecessary complexity.
However, I'm fairly sure the the Markup* tiddlers were introduced
because there are static bits that have to be in a particular place at a
particular time, and thus cannot be loaded on the fly.
I'd be happy to be corrected on this, but I think it's a HTML/DOM issue
that TiddlyWiki can't get around.
-- F.
Jeremy Ruston
include HTML that doesn't work in a tiddler context (document.write
being the main example). So, if you've got to include a <script> tag
to incorporate Google ads, you need to have a foothold in the actual
static HTML file that gets served to the browser, it's too late to do
anything once the javascript is up and running.
(This discussion is applies somewhat to the handling of the <title>
tag that also needs to be filled in as part of the TW baking process).
Like you, I like the fact that you can make a functional TW document
with a single splice, but I tend to think of that approach as being
for quick-n-dirty proof of concepts, needing more elaborate templating
to make the thing work properly. I see it that TiddlyWeb wouldn't have
any specialist knowledge of things like Markup* tiddlers, they would
just be visible in the template itself.
CHeers
Jerm
chris...@gmail.com
On Jul 3, 12:01 pm, "Jeremy Ruston" <jeremy.rus...@gmail.com> wrote:
> The purpose of the Markup* tiddlers is indeed to enable authors to
> include HTML that doesn't work in a tiddler context (document.write
> being the main example). So, if you've got to include a <script> tag
> to incorporate Google ads, you need to have a foothold in the actual
> static HTML file that gets served to the browser, it's too late to do
> anything once the javascript is up and running.
things to the TODO.