Hi, some reply to Jeremy inline:
On Nov 15, 7:16 pm, Jeremy Ruston <[email protected]> wrote: > I like the way that people explore using TiddlyWiki with different, > pre-existing serversides, such as the current experimentation with > CouchDB, and Zooko's experiments with Taho-LAFS. > > My concern is that different serversides may have somewhat different > semantics for their UUIDs, and it would be bad for TiddlyWiki to get > in the way of experimenters by imposing a slightly incompatible way of > using UUIDs. True, but that is what adaptors are for. If we define a uuid field for tw, I imagine it would be a long random looking string. The exact format of this string is not so important, as long it is not equal to some other. Obviously different server sides will have different uuid's, and they can keep it in an optional sever field in the tiddler if required. So I think this server uuid can be different from the tw uuid, but it would be nicer (and really preferable) if they were the same. > > I know it's not quite the same thing, but a related thing that I would > like to see standardised is the field that identifies the global URI > for the canonical copy of the content of a tiddler. It seems > reasonable for future TiddlyWiki to directly support clean, RESTesque > serversides like TiddlyWeb by using HTTP verbs on that URI. > Yeah, a uri field would be nice. I would not count on REST like server sides, I think that would be a grave limitation. Think of other server access methods (protocols) like WSDL, XML-RPC, http with cgi and RSS. These are not RESTy, but interesting for tw > > 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. > > I'm not sure that fixing an implementation within TiddlyWiki is the > best way to find the optimum federation architecture. The core of the > tiddler concept is pretty well established now, as Chris says, there's > more than one implementation that we can use as a reference. Let's > record what we've got as the core tiddler standard, and make sure we > leave space for the experiments on federation and sharing. The thing is if different servers define a different name for the uuid fields, then sharing and federation is hard. As long as the format of the uuid is basically a long string, the format of this uuid is of minor importance. In my view federation really starts at the standalone tw. You then might put tiddlers on one server. Then you might change the tiddler and put it on a different server. And then you might email a tw to a friend. This is some form of federation, where a server based uuid not really helps, if you want to track the identity of the tiddlers. > > Part of my resistance is that I'm concerned that the consequences of > enforcing UUID semantics on the client seem complicated. They seem > straightforward enough when thinking in terms of how the > synchronisation works, but I'm less confident when it comes to the > user interface; on the face of it, UUIDs would allow multiple tiddlers > with the same title field to exist. How would it choose the right one > for navigating links? How would users access the others? I'm > disinclined to start grappling with all of that when it's not strictly > a prerequisite for exploring the actual underlying federation and > sharing mechanisms that so many of us are interested in. > For the client tw adding a uuid doesn't matter directly. It wouldn't allow for tiddlers with different titles to exist, as it is forbidden in tw now. It would be just an extra field. In fact just introducing a uuid field needs no user interface. And the problem of different tiddlers with the same name doesn't change if they have different uuid's. However uuid's could help to distinguish if there were a user interface. Have a look at Ward's wiki. As a user you never see the uuid, it is just used by the client and server to track changes and different pages. The uuid is important to establish a standard a server or another client can count on. -- 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.
