Hi, @Jeremy: For me a tiddler uuid has nothing directly to do with a tiddler. At creation time put a uuid in a field in the tiddler is the absolute minimum I think tw should do. A lot other stuff can be done server side. The advantage of creating a uuid at tiddler creation time is that then it is "uniquely" marked. Then the tiddler might move to a server (or not). My thought is that by putting the uuid in tw, all servers should support this standard. If each server builds up its own uuid semantics, than its hard to get federation and sharing of tiddlers peer to peer without a server.
@Chris What I mean by a tiddler communication protocol is more a set of conventions than a tech specification like http or tcp/ip. In the protocol we need: which fields are part of a tiddler, which fields are optional, what is the meaning of the fields (e.g. changes the uuid with each edit? Or is there a version identifier?). In you first post from nov. 11 you make a proposal for such a protocol as I mean it. I suggest to additionally look at Ward's pages definition in JSON, because it is very similar to a tiddler and already solves in some way versioning, uuid's and tracking servers. How you then actually send the tiddlers? Probably just http/atom as you stated. And probably the uri/url's to get a tiddler will be server dependent. That is not a problem. The problem to be solved it what do you get back when you call GET /some.tiddler.json? Which fields are in the tiddler and what do they mean? -- 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.
