Hi Jeremy, > The problem here is that updating the tiddler with the new revision would > constitute a change to the tiddler, triggering it to be saved once more to > the server, which in turn would generate a new revision number, repeating the > whole cycle.
> The "new tiddler" mechanism doesn't know anything about the revision field, > and so just blindly copies all the fields of the original tiddler into the > draft. OK, is there a way of getting the newest revision from the syncer's tiddlerInfo inside the saveTiddler method? Maybe it could be passed to saveTiddler like it is passed to deleteTiddler? This would probably fix both issues since the sync adaptor can store the server revision inside the tiddlerInfo and distinguish between a draft tiddler it has not seen before (that has the original tiddler's revision) and a draft tiddler that already exists on the server. Regards, William On 24 September 2014 10:19, Jeremy Ruston <[email protected]> wrote: > Hi William > >> I am trying to write a sync adaptor for CouchDB > > Terrific, I'm very happy to hear this. > > One CouchDB feature that I'm very interested in is the ability to use views > written in JavaScript. I believe that it ought to be possible to package the > TW core code as a view so that CouchDB can dynamically build TiddlyWiki's on > the server. > > In terms of revision handling, one point to note is that by design the core > itself is not aware of the revision field; it is entirely implemented within > the syncer module and any syncadaptor modules that need it. I wanted to do > it this way so that we could develop new syncer modules that use a different > basis for tracking revisions. > >> * why the updated revision returned from saveTiddler is not stored in the >> tiddler itself > > The problem here is that updating the tiddler with the new revision would > constitute a change to the tiddler, triggering it to be saved once more to > the server, which in turn would generate a new revision number, repeating > the whole cycle. > >> * why a new draft tiddler's revision is set to the original tiddler's >> revision instead of null > > The "new tiddler" mechanism doesn't know anything about the revision field, > and so just blindly copies all the fields of the original tiddler into the > draft. > > I'm very keen to support you on this work, please feel free to ask further > questions! > > Best wishes > > Jeremy > > > > On Wed, Sep 24, 2014 at 10:27 AM, William Shallum <[email protected]> > wrote: >> >> Hi Mario, >> >> Thanks for the explanation. So it seems that the revision field is >> treated as an opaque string by the TW5 app. The syncer just checks if >> the revision returned from getSkinnyTiddlers is different between the >> client and the server and refreshes the existing tiddler on the client >> if it is different. >> >> How does tiddlyweb detect conflicts using the tiddler's etag in the >> current implementation? In tiddlywebadaptor.js the etag is not sent >> with the request and you said that the revision sent from the client >> is always ignored. >> >> Regards, >> William >> >> On 24 September 2014 14:25, PMario <[email protected]> wrote: >> > On Wednesday, September 24, 2014 12:51:07 AM UTC+2, William wrote: >> >> >> >> Thank you for the explanation. I am not asking about what the _rev is >> >> used >> >> for in CouchDB. I am asking about how the TW5 app (syncer and the app >> >> in >> >> general) handles the revision field, especially: >> > >> > >> > Are you talking about the mechanisms used in syncer.js and may be >> > tiddlywebadaptor.js? >> > The revision handling there is in line with the TiddlyWeb backend >> > behaviour >> > but TW5 doesn't know about revisions yet. >> > TiddlyWeb keeps permanent revisions of every tiddler. >> > >> >> >> >> * why the updated revision returned from saveTiddler is not stored in >> >> the >> >> tiddler itself >> > >> > >> > That's probably a bug. But at the moment, it doesn't matter. Since there >> > are >> > no conventions defined, how to deal with "backend fields" in a tiddler. >> > IMO what we have here is a _naming conflict_. So I think, what is >> > needed, is >> > a general discussion, how to handle fields, that are needed to deal with >> > a >> > specific backend. >> > >> >> >> >> * why a new draft tiddler's revision is set to the original tiddler's >> >> revision instead of null >> > >> > >> > That's probably a bug. But in the tiddlyweb context the revision sent >> > from >> > the client is always ignored by the server. >> > The server creates a new revision, when it saves something. Conflict >> > detection is done with the tiddlers etag. >> > >> > ----------------- >> > >> > The only field every tiddler must have is: title >> > >> > Common fields are: >> > - modified, modifier, created, creator, tags, text >> > >> > Application specific fields can be seen at: tiddlywiki.com: >> > It has a lot of them: >> > http://tiddlywiki.com/#%24%3A%2Fcore%2Fui%2FControlPanel%2FTiddlerFields >> > >> > Empty TW: >> > tiddlywiki.com/empty.html has: >> > >> > http://tiddlywiki.com/empty.html#%24%3A%2Fcore%2Fui%2FControlPanel%2FTiddlerFields >> > >> > So what we need is some type of namespace, that separates backend fields >> > from "common" and "application" fields. >> > >> > With TiddlySpace a prefix "server." eg: server.bag, server.content-type, >> > .etag, .permission, .recipe. ...... was introduced, >> > but these prefixed fields are explicitly removed by the TW5 import >> > mechanism. see issue #238 >> > >> > There are some open issues eg: >> > - https://github.com/Jermolene/TiddlyWiki5/issues/689 >> > - https://github.com/Jermolene/TiddlyWiki5/issues/238 >> > >> > So imo we need to deal with these issues and the namespace discussion >> > first. >> > Otherwise different backends will create a big field naming mess. >> > >> > @Jeremy, >> > What do you think? >> > >> > just my 2 cents >> > Mario >> > >> > >> > >> > -- >> > You received this message because you are subscribed to a topic in the >> > Google Groups "TiddlyWikiDev" group. >> > To unsubscribe from this topic, visit >> > https://groups.google.com/d/topic/tiddlywikidev/TSwYsd0ZxFw/unsubscribe. >> > To unsubscribe from this group and all its topics, send an email to >> > [email protected]. >> > To post to this group, send email to [email protected]. >> > Visit this group at http://groups.google.com/group/tiddlywikidev. >> > For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "TiddlyWikiDev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/tiddlywikidev. >> For more options, visit https://groups.google.com/d/optout. > > > > > -- > Jeremy Ruston > mailto:[email protected] > > -- > You received this message because you are subscribed to a topic in the > Google Groups "TiddlyWikiDev" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/tiddlywikidev/TSwYsd0ZxFw/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/tiddlywikidev. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/tiddlywikidev. For more options, visit https://groups.google.com/d/optout.
