The Road to 1.0
Chris Dent
I think if I had my druthers, TiddlyWeb would be in eternal alpha,
forever evolving with little regard to ever achieving stability and
we'd all be happily evolving along with it.
But that's not really a great way to get a piece of software out there
in the world and useful to lots of people.
So if we'd like to get TidldyWeb out with the world, it needs to get a
1.0 slapped on it. To make that happen some combination of me or we
(we would be best) need to do some things (in something like this
order):
* Enumerate those features which are missing (but required) or
superfluous and add or remove them as necessary.
* Enumerate those features which are missing but should either be
plugins or left until post 1.0 (i.e. will not cause a disruption by
their later addition).
* Once the features are stable, freeze the code base and start a
release candidate cycle, stomping bugs.
* Audit the documentation and fix any gaps.
This seem like a reasonable plan?
(I realize the current discussion about tiddlywiki-ness as core or
plugin needs to be resolved as part of all this.)
chris...@gmail.com
> * Enumerate those features which are missing (but required) or
> superfluous and add or remove them as necessary.
* Pulling tiddlywiki-ness to a plugin. This has been easier than I
thought it would be but may present social challenges. However,
decoupling TiddlyWebWiki from TiddlyWeb appears to make the road to
TiddlyWeb 1.0 much shorter as there a _lot_ of TiddlyWiki-side things
that need to happen (which I'm not enumerating here).
* Recipes within recipes. Doing this is harder than I wanted it to be
because the various serializations and store formats of recipes
currently have no awareness of what sort of thing the string in the
first half of the bag/filter tuple is in a recipe line. This means
that adding recipes in there is crufty for a what may not be
sufficient gain. Or there may be other ways to achieve the same
results. So I'm not aching to get this in 1.0 and maybe never.
* twanager commands that update rather than replace existing Users and
other entities. Right now if you want to add a Role to a User, you
have to reset their password. This is not great.
* A generic web-interface for administrating entities in the store.
This could be entirely javascript, but should _not_ be TiddlyWiki
dependent.
* Support for a sort of auto-synching, so a set of tiddlers that are
out there in some form (perhaps a TiddlyWiki) can self update when
there are sufficient changes on the server for the out there stuff to
be considered stale. This can probably be handled entirely client side
by making reasonable queries to the server.
* Etag and other cache headers for bags, recipes, and filter and
search results.
* Stabilize binary tiddler handling.
* A proper recent changes interface. (This may have impact on the core
because how revisions are thought of while handling a list of tiddlers
might need to change.)
* A fuller featured implementation of a store plugin that has a search
system that uses an indexing system. This is not part of core, but may
need to exist before a 1.0 because it demonstrates an important
feature for which a demo plugin has yet to be created (there are demos
for most other pluggable features).
chris...@gmail.com
* localization of server-side strings
chris...@gmail.com
Here's an update on progress or lack thereof on the "Enumerate those
On Jul 3, 2:04 pm, "cd...@peermore.com" <chris.d...@gmail.com> wrote:
> * Pulling tiddlywiki-ness to a plugin.
http://github.com/tiddlyweb/tiddlywebwiki/tree/master
> * Recipes within recipes.
This won't happen before 1.0.
> * twanager commands that update rather than replace existing Users and
> other entities. Right now if you want to add a Role to a User, you
> have to reset their password. This is not great.
addrole: Add a role to an existing user. <username> [role] [role]
[role]
userpass: Change the password of an existing user. <username>
<password>
commands on twanager.
> * A generic web-interface for administrating entities in the store.
> This could be entirely javascript, but should _not_ be TiddlyWiki
> dependent.
FND, Jeremy or JonL have some knowledge of where these things can be
seen.
> * Support for a sort of auto-synching, so a set of tiddlers that are
> out there in some form (perhaps a TiddlyWiki) can self update
similar to the following:
select=modified:>200906
every now and again.
No progress in this area. Not (yet) heard a lot of demand for it.
> * Etag and other cache headers for bags, recipes, and filter and
> search results.
recipes.
> * Stabilize binary tiddler handling.
to get a sense of where the lack of stability.
> * A proper recent changes interface.
> * A fuller featured implementation of a store plugin that has a search
> system that uses an indexing system.
> * localization of server-side strings
Anyone have any items they'd like to add or remove?
Jeremy Ruston
>> This could be entirely javascript, but should _not_ be TiddlyWiki
>> dependent.
>
> There are a couple of experiments in this vein in progress. I think
> FND, Jeremy or JonL have some knowledge of where these things can be
> seen.
I did a mockup of an admin interface some time ago, and Fred and JonL
are now planning to implement it later this week:
http://peermore.com/misc/TiddlyWebAdmin.pdf
Cheers
Jerm
--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com
chris...@gmail.com
wrote:
> > search results.
>
> Present for filter and search results. No progress, yet, on bags and
> recipes.
people think these things should be based on the recipe and bag itself
changing, or the things they generate or contain (respectively).
For example when a bag's policy or description is changed, that could
change the bags modified time, but not when a tiddler is added. Should
a tiddler addition change it?
> > * A fuller featured implementation of a store plugin that has a search
> > system that uses an indexing system.
>
> No progress.
that they enjoyed. There are several.
FND
> people think these things should be based on the recipe and bag itself
> changing, or the things they generate or contain (respectively).
Well, I'm not sure I fully understand the implications here.
Aren't there two separate cases for requesting bags/recipes:
Since /<container>/<name> refers to the respective container itself, the
headers should too.
Similarly, /<container>/<name>/tiddlers referes to the container's
contents, so that (the tiddlers, not the container itself) is what
should be taken into account there.
> Does anyone have experience with a Python-based search index/engine
> that they enjoyed. There are several.
Not me, I'm afraid.
This discussion might be of interest:
http://stackoverflow.com/questions/438315/is-there-a-pure-python-lucene
-- F.
Chris Dent
On Aug 2, 2009, at 10:14 AM, FND wrote:
>> Regarding ETag and lastmodified headers for recipes and bags. Do
>> people think these things should be based on the recipe and bag
>> itself
>> changing, or the things they generate or contain (respectively).
>
> Well, I'm not sure I fully understand the implications here.
> Aren't there two separate cases for requesting bags/recipes:
> Since /<container>/<name> refers to the respective container itself,
> the
> headers should too.
> Similarly, /<container>/<name>/tiddlers referes to the container's
> contents, so that (the tiddlers, not the container itself) is what
> should be taken into account there.
Yes, that makes sense.
To implement this is going to require adding modified attributes to
the Bag and Recipe models as well as code in stores to read and write
those attributes. Which means that it will need to have a bit of
smarts in it to deal with data in the store that does not yet have
that attribute, such as saying 'modified' = now() if there is no
modified attribute.
Which is fine but somehow meh.
I'll think on this a bit more.
chris...@gmail.com
wrote:
> > > system that uses an indexing system.
>
> > No progress.
>
> Does anyone have experience with a Python-based search index/engine
> that they enjoyed. There are several.
development, and nicely featured.
The plugin that I created overrides code in
tiddlyweb.web.handler.search to go to a whoosh index instead of the
current store to satisfy a search request. The index is updated
whenever a tiddler is written. There are twanager commands that will
reindex the entire store or perform a search from the command line.
The code can be found on github:
http://github.com/tiddlyweb/tiddlyweb-plugins/tree/master/whoosh
It's not (yet) well documented.
[1] http://whoosh.ca