On Nov 11, 9:44 am, Tobias Beer <[email protected]> wrote: > Probably rather quickly we end up with a lot of what TiddlyWeb already > has implementations for, like roles, recepes, bags atop of the atomic > thing at the heart of it all... called a tiddler... and a > serialization that wraps the stuff and sends it across the web. > > If these data are then communicated via some bloated XML or a perhaps > way more streamlined JSON pattern... that would not even have to be > part of the standard, but just different means to serialize all the > bits and pieces required for communication ...via some library > implemented in whatever serverside environment is to ones liking. > > The protocol / exchange formats should be simple and clear, just like > the concept of a tiddler.
I'm not really sure what I can add to this, because I pretty much agree with what you've said. TiddlyWeb already provides an architecture for moving tiddlers around and it is pretty straightforward because it uses HTTP. And tiddlers in TiddlyWeb are pretty easy to identify because the URI of the tiddler _is_ the tiddler. This is all standard and entirely intentional aspects of TiddlyWeb being a true web application (i.e. psuedo- RESTful). The serialization model in TiddlyWeb makes it possible to send and receive tiddlers however you like and persist them in a way that is independent of how they are sent. Again, standard and entirely intentional aspects of being a good web app. I think the issues that "tiddlygrp" and a few others have pointed out are: 1. There's no standard format. 2. Tiddlers don't have UUIDS, thus lending themselves to free-floating in a global distributed network. On 2, that's a simple matter of programming. We can make it so tiddlers have uuids, but then you need to decided if/when those uuids change. Do you get a new uuid per revision? Does the uuid stay the same or change if the tiddler is renamed? Or do you keep a history, as in proper version control and enable some git like handling? On 1, I personally think tiddlers are both simple enough and have establish enough of a precedent that we can go with what's already being done along with some light improvements. A tiddler is a lightly nested dictionary: * title: string * modifier: string * creator: string * modified: date§ * created: date§ * text: string (binaries encoded as needed) * type: string (content-type of text) * revision: an arbitrary identifier for this revision * tags: list of strings * fields: dictionary of arbitrary string:string pairs § how to represent dates would need to be resolved The shortcomings in the above is that this tiddler, internal to itself, does not disambiguate itself from another tiddler with the same title. In TiddlyWeb this is handled by the bag concept, but that is presumably not a universal concept in the tiddlyverse. Thus some kind of uuid, or uri would be desired as well. OR it's entirely reasonable just to say "the inter-server transport is Atom", because that would work too. Atom is capable of representing tiddler just fine (with some tweaks for arbitrary fields). Or perhaps JSON activity streams. Note that most of this "syntax and semantics for tiddlers" was driven by the model established in the TiddlyWiki AdaptorMechanisn, which adapts server content (of many types) to TiddlyWiki Tiddler objects. TiddlyWeb's understanding and modeling of a Tiddler object is quite similar but a bit different (to deal with bags and recipes and real revisions). The difference, though is easily handled at the interface between TiddlyWeb's core and the serializations that it uses for transport. Very happy to answer more specific questions, but without some direction I'm not sure what else to say. -- 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.
