I suppose whether or not UUID's make sense as an attribute of a tiddler depends on how you define it's identity. Which has 3 aspects that I can think of: 1: Who wrote it ? 2: Where does it physically or logically reside ? You should be able to edit it whether offline or online - ideally the merge should happen automatically. 3: What's the history ?
Each of these may have simple answers in one use case, but complex answers in another: 1: A tiddler may have been modified by several people. 2: The need for it to reside on a server and/or on a pocket device at various points in time is perfectly valid. 3: I don't think the title is a sufficiently robust handle in all cases, obviously not if you require the ability to rename it and still preserve history. Basic TiddlyWiki of course relies on the combination of a title and a physical location for identity. Which is a healthy idea from the point of view of the user working with a single, classic kind of document, but it does present some problems as soon as the context changes: * collaborative editing. * federating content. * simply copying it to a different location and forgetting where the most recent version is... One of the desirable aspects of TW is that it breaks the document into more manageable pieces, that ought to make the process of merging changes more automatic. Adding the UUID goes some way towards reducing this problem, but it doesn't solve it completely. At some point you are still going to be faced with the problem of branching and have to decide how you want to deal with it. Giewiki uses UUID's and version numbers to define identity and history. It allows you to take a page offline, edit it as a classic TiddlyWiki and merge your changes back as long as there is no conflict. Conflict is detected based on tiddler version numbers, but it currently does not offer any help in resolving them, except by making it easy to compare the text of any two versions (without presenting them as separate tiddlers like I believe TiddlySpace still does). It naturally still retains the human-friendly requirement that the titles of the tiddlers be unique within a document. The versioning feature also allows you to specify that a version other than the most recent is the current one (i.e. served by default). I do not reserve a handy syntax for including a version number in a URI -that would be via the query string. Most recently, I've built an auto-save feature on top of this, and added the ability to customize which fields should be listed in the version history. A more ambitious plan to support the same editing experience whether online or offline (using the GAE SDK server) still sits somewhat low on my to-do list together with the idea of putting a custom Python interpreter into IOS - dunno if that would be allowed if restricted to just run your server. ;-) Poul http://code.google.com/p/giewiki/ || http://giewiki.appspot.com/ On 14 Nov., 13:47, Jeremy Ruston <[email protected]> wrote: > I'm very interested in the work that's going on around federation, and > I'm also drawn to the value of robust history tracking for tiddlers, > and agree that that is one of the key roles for servers in the > TiddlyVerse. > > I've found myself less keen on making UUIDs be a part of the core > definition of a tiddler. I can see that there are some scenarios that > need UUIDs to work, and so I'm interested in ensuring that the core > definition of a tiddler allows for the use of UUIDs (the simplest way > being to choose to use UUIDs in the title field, and use a different > field for the human readable title). I don't see a role for UUIDs in > the TiddlyWiki core, rather I see their usage being driven by server > side (or federation) concerns. > > Adding UUIDs to the core tiddler model would make tiddlers more > specific to a particular class of servers and/or federation systems. > Some of these systems might well want slightly different semantics for > UUIDs. If the tiddler concept is to be universal then I think it needs > to be surgically minimal: it is primarily about cutting up information > into little chunks, and the details of particular persistence or > federation approaches using UUIDs shouldn't intrude on the core model. > We want the idea of a tiddler to be as simple as possible so that as > many people as possible can agree on it. > > Best wishes > > Jeremy > > > > > > > > > > On Mon, Nov 14, 2011 at 10:56 AM, tiddlygrp <[email protected]> wrote: > > Hi Chris, > > > the example of Ward's federated wiki was chosen because he has already > > build a simple json representation of pages (something like a tiddler) > > with uuid and semantics to track changes. This could be easily > > adapted for tw. > > In my view uuid's are something for the computer to track. They > > should be used for versioning and disambiguation etc. For the user > > the tiddler names are more important. So we need to define their > > relation. > > > some replies follow inline: > > > On Nov 12, 3:00 pm, [email protected] wrote: > >> On Fri, 11 Nov 2011, tiddlygrp wrote: > >> > I thing the most important are the definition of uuid fields and their > >> > semantics and working together with tw, including the ability to track > >> > changes and the history of where the tiddler came from. I think this > >> > is non trivial. > > >> Can you give a few more details on what the communication protocol > >> would be accomplishing? I acknowledge that it would be cool to do, > >> in the abstract, but knowing some more concrete reasons for having > >> it will help to understand the structuring that we need to do. > > >> I ask because earlier this year I was getting quite keen on > >> federation in general, and federated social web protocols, but over > >> time I've come to wonder about the extent to which they are really > >> necessary above straight up HTTP and hypertextual links. In the FSW > >> world, federation has come to mean distributing copies of stuff all > >> over the place. I think this is entirely regressive and > >> counter-productive on an open and public web. We don't want copies > >> of content, we want more links (with links that actually work), and > >> more servers. > > > Once you edit a tiddler from someone else you basically fork it. I > > think in some way history should be preserved for that. I am not > > advocating replacing links, but a mixing up tiddler content from > > different hosts is very powerful i think. > > > I also think it is important to view the history of a tiddler: what > > was written here 2 years ago? > > >> Ward's information makes it pretty clear that part of the goal in > >> his stuff is a collaborative workflow. Is this the sort of things > >> you are thinking about? > > > thats an interesting development, but not my main motivator. > > >> In that context, how important is tracking changes and history > >> compared to the content itself. I've been working on collaborative > >> content systems for a long time now and one of my observations is > >> that strict content tracking is far more important in code than it > >> is in narrative. And not only that, because of the structure of code, > >> tracking the changes is far _easier_. > > >> Given that I keep finding myself coming back to a situation where if > >> the content is fairly unstructured human communication what we need > >> is just accessibility. > > >> In a tiddler context that means URIs for individual tiddlers with > >> good capacity to link. > > > I think one does not exclude the other. The uuid for a specific > > version could map to a uri. > > > I think it should not be required for a server or tw to track al > > history. But i think it is prudent and quite easy (at the onset) to > > allow for a tiddler definition which allows this history and merging/ > > fork tracking. A server just can ignore it. But you can also use it > > when you want. > > >> Can you provide a use case or user story that fleshes out the need > >> for what you describe above? I'm not saying it doesn't exist, I'm > >> sure it does, I would just like to understand it more clearly. > > > A possible (hypothetical) story goes like this: I see the > > tiddlywikki.com page, take it to my tw and change it. Jeremy wants to > > take back some of my changes into the original tiddlywiki.com page. > > Without a tiddler protocol supporting this, it means using something > > like diff and patch which is for experts only. > > > Another story: I predict in 2011 that in 2012 there are more tw > > users. In 2012 i update the tiddler to reflect new data. A reader > > can then look up in tiddler history what I precisely said in 2011. > > > Another one: I use tw for todo lists. When a job is done it gets > > marked. Once every month i clean the list of done jobs. But what did > > i do a year ago? just look up the history. And now my friend likes > > the system. He just forks the tiddler to his own tw, keeping a > > history reference to my tiddler. If i improve the system, he gets > > (actually he queries my tw for an update) a notification, because his > > tw is still tracking my tiddler because it keeps "federated server > > history". > > > Hope that makes my thoughts more clear. > > > -- > > 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 > > athttp://groups.google.com/group/tiddlywiki?hl=en. > > -- > Jeremy Ruston > mailto:[email protected]://www.tiddlywiki.com -- 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.
