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].
* 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.
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
On Jun 20, 5:58 pm, "cd...@peermore.com" <chris.d...@gmail.com> wrote:
> 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 tohttp://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].
> * 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.
> 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.
>> Do people mind TiddlyWeb discussion happening on TiddlyWikiDev, >> 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.
> 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 architecture is going to work out nicely.
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().
> > * 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.
Few different forces at work there:
* 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.
There are the things mentioned in the start of this thread. I can make
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().
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.
> For reasons I don't understand, the community wiki is completely not > 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).
>> > 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().
> 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".
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).
Cook does handle MarkupPre/Head/Post/Body tiddlers but it does not do 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)
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.
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.rus...@gmail.com>:
>>> > 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().
>> 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
