Hi Jeremy, Thanks for making the changes so quickly. I will let you know when it is done.
Regards, William On 24 September 2014 11:16, Jeremy Ruston <[email protected]> wrote: > Hi William > >> 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? > > > Yes that makes sense, I've added it here: > > https://github.com/Jermolene/TiddlyWiki5/commit/a159b5baf3ad91d8defc68cbf81c78d01b69c416 > >> >> 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. > > > Great, let me know how you get on, > > Best wishes > > Jeremy > >> >> >> 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. > > > > > -- > 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.
