Hi, Thanks Poul for your reply. As you said different use cases for uuid's and identity would lead to different designs. I think we nonetheless should standardize on something and say tiddler standard version 1 somewhere in a tiddler field. Then we can upgrade later on always.
@Tobias Your last post makes it as if it is a heavy burden to do the uuid stuff which would be better done on a server. I don't think so. It can (should!!) be done client side. And you propose a quite heavy process with naming conventions and standards. I would rather define a minimum and leave extensions open. Client side examples which would benefit from a minimal uuid standard are: there where (are) some tw's who exchange tiddlers through rss with no server explicitely involved. The same goes for upgrading a tw. How does tw know if a plugin has changed? Some brittle convention. If there was a machine readable date field and uuid a tw could "know" that a plugin was newer. I think in the tw universe it is important to have the basic uuid capabilities in the client (tw). @Chris and others I mentioned Ward's federated wiki quite some times because he has a concrete specification: https://github.com/WardCunningham/Smallest-Federated-Wiki/wiki/Story-JSON { "title": "Welcome Visitors", "synopsys": "The first federated wiki page written and often first page viewed.", "story": [ { "id": "7b56f22a4b9ee974", "type": "paragraph", "text": "Welcome to the federated wiki. This page was first drafted Sunday, June 26th, 2011, at indie-web-camp. You are welcome to copy this page to any server you own and revise its welcoming message as you see fit. You can assume this has happened many times already." }, { "id": "8d8a6cf94b72e848", "type": "image", "width": "300px", "height": "200px", "caption": "Ward's Lighted Electric Bike at [http:// www.shift2bikes.org /cal/viewpp2011.php#24-2144 Pedalpalooza]", "url": "/lit-and-loud.jpg" } ], "trail": [ "http://fw.indiewebcamp";, "http://c2.com/~ward/fw"; ], "journal": [ {"type": "edit", "id": "15411293042b2735", "text": "the paragraph now says this"} ] } This looks somewhat similar to the tiddlyweb JSON for a tiddler. The main difference is the use of the id's (uuid's) and the journal. the journal is what helps do track changes and I would propose to add it additionally to uuid's. But I would leave using the journal optional. That would mean there is a standard way to track history and merges, but a client or server is not obliged to use it. A creator/editor field would be nice also. However without authentication/cryptographic signing it probably will be forged sometime and it will be more of a convention than a reliable authorship field. Now also cryptographic signing could be nice for tiddlers and I could think of a lot of additional possibilities. Therefore the tiddler field protocol should be extensible with optional fields which can be ignored at will through a client or server. The main problem is as Chris stated: >Okay that makes more sense. I'm not sure how or who to decide the >syntax and semantics. For that we need some process. -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To post to this group, send email to tiddlywiki@googlegroups.com. To unsubscribe from this group, send email to tiddlywiki+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
