On Jan 27, 6:24 pm, [email protected] wrote: > On Tue, 25 Jan 2011, Poul wrote: > > I - of course - must recommend giewiki as an alternative to > > tiddlyspace. > > I think it is great that there are plenty of options, but this > message seems like an invitation to respond with some compare and > contrast, perhaps so all systems can improve, so here goes: > > > The pros and cons executive summary goes something like: > > + Better revision control, including diff and revert > > This is a "simple matter of programming" at this point. Perhaps there > is code in giewiki that can be borrowed? TiddlyWeb (the guts > underneath TiddlySpace) stores revisions but does not provide in > itself tools for diff and doing revert. That's taken as the > obligation of the client side: TiddlyWeb provides the storage api.
Of course, you are free to borrow my solution from giewiki. It's done server-side though. I probably don't understand TiddlyWeb well enough to say for sure, but my immediate reaction would be to observe that a web arcitecture that leaves all kinds of application-level duties to the client is going to be a very insecure one - just as you wouldn't expose SQL directly to the client. I'm not saying that giewiki scores high on security, but I am taking a more pragmatic approach when it comes to placing the detailed responsibilities. The main reason I did giewiki is that I felt that so much could be achieved by combining TiddlyWiki with a server-side, which wouldn't be appropriate to client-side. > > > + Recent changes, recent comments, tree structure, SiteMap, page > > templates, etc. > > Ditto on the above. TiddlyWeb lets you use whatever tools you want > for doing those kinds of things. If you have tiddlywiki plugins > which do those things, magic. > These are examples of features that are implemented server-side in giewiki, for reasons of security and performance. > > - It's currently a fork of TW 2.4.1 > > tiddlywebwiki, the package the includes the empty.html used with the > wiki serialization tracks the latest stable release. TiddlySpace > itself has functionality that allows a request to optionally use > whatever the latest beta TiddlyWiki is. > > > + It's only 320K before content, as compared to 770K for TiddlySpace > > Yeah, this is a big problem with TiddlySpace. On a plain > tiddlywebwiki it's 421K, which is still too much. > Which is one of the reasons that I chose to trim the TiddlyWiki code. The second was that my first attempt used unmodified TW 2.0.x code, only to find that later changes to TiddlyWiki broke my code. > > + It's cloud-based, which means Google will host it on redundant > > servers for little or nothing. > > TiddlyWeb can run on app engine[1] just fine, and it would be no big > deal to make TiddlySpace do the same. It's been useful thus far to > have it on its own server for the sake of tweakability. > > All that said I think the biggest win for TiddlyWeb (and excuse me > if giewiki has this stuff too, I had a look round the code but it > wasn't immediately obvious) is that it is explicitly designed to > make Tiddlers first class entities on the web. They have their own > URIs, can be represented in multiple (and extensible) content-types > (common ones are text, json, in-a-tiddlywiki, html and atom), can > contain any content (including images) not just wikitext, and > can be reused, by reference, across multiple wikis or other collections. Tiddlers in giewiki obviously also has their own (path#name) URI's (plus a GUID to allow stronger identification), although currently you cannot retrieve a single tiddler. I'm not saying that the currently available modes of retrieval are all that anyone could want, though. > > TiddlyWeb makes very few assumptions about how those tiddlers are > going to be used and who is going to use them. It's proven quite > remarkable, actually, taking the tiddler concept out of tiddlywiki > and thinking of them as free floating bits of content. This may be very powerful in theory, but if you want to to pull in twenty plugins from different servers, it's going to have an impact on performance. giewiki addresses this problem by caching copies of the content that you include, then builds a page template mechanism along the same lines. > > That makes it very flexible, but also means that it does not have > the level of focus that giewiki has: "giewiki tries to be a real > wiki". [3] > > In specific context of tiddlywiki.org, right now I think the winning > proposition for TiddlySpace is the inclusion functionality that allows > the content to be distributed across multiple spaces. I've already include > the tiddlywikidev space into the tiddlywiki space, meaning that a large > collection of developer oriented content (mostly explaining available > methods in the core) is just there. Excuse me for not seeing the magic of including one set of tiddlers in another. giewiki has that too, although currently only by reference to the specific set of tiddlers that you want to include. Problems seem to arise when you want to include all (current and future -if that's what you do) because of namespace collision and confusion (to the reader) of context and conflicting use of terms (Accidental/automatic links may be great, but I'm not sure they are helpful without human sanity checks). Actually, such inclusion is to me something that should be left to the discretion of the reader. All in all, I think the best route would be to leave the choice of future platform to someone with an unbiased point of view. /Poul Staugaard -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
