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 <tiddly...@gmail.com> 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, chris.d...@gmail.com 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 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. > > -- Jeremy Ruston mailto:jer...@osmosoft.com http://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 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.
