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 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.

Reply via email to