On 10/25/05, Thomas Broyer <[EMAIL PROTECTED]> wrote: > Luke Arno wrote: > >>>> So you'd be happy with being forced to resolve conflicts *just* because > >>>> you used two different AtomPP clients and offline editing, even you > >>>> *know* > >>>> you are the only user having access to the resource? > >>>> > >>> It is not about what makes me happy. It is a physical reality, > >>> unless you want to risk lost updates. > >>> > >> By "forced to resolve conflicts", I meant *you* as the end-user, not > >> your AtomPP client. This can be prevented if your AtomPP client is able > >> to sync "accurately" with the AtomPP server, that is if it is told an > >> entry has changed even if its atom:updated has not be changed. > >> > > > > Of course the machine should figure out as much as it > > safely can. I did not suggest otherwise. > > > > Do you use CVS or Subversion or something? Like that > > only in a pretty interface, probably. > > > Every day. > > I used to use the command line on a Linux box (some years ago when > working on libxml/libxslt/libexslt) but developing in .NET with Visual > Studio (so, on a Windows station) at work, I find it easier to use > TortoiseCVS as a front-end (but please, don't tell me about anything > integrated into the IDE, as SourceSafe in VStudio)
Cool. I use libxml/libxslt practically every day. Visual Studio will rot your brain, however :) > > How conflicts are resolved is orthogonal to how conflicts > > are detected. > > > A major difference is that diff/merge is part of those VCS (there's a > conflict when committing? just update and commit again, in 999 over > 1,000 cases this will be enough because CVS/SVN will merge changes in > different parts of the file) but not of AtomPP. > I think that many AtomPP clients will end up diffing/merging in a near > future, but that may be a little too much for a mobile client ala > LifeBlog (or worse: a J2ME client) Is it really too hard for them? Will this be true 1 year from now? I don't know. That is a good question but feels like an edge case. > >> I meant this: > >> POST an entry E using client A > >> Sync with client B (client B retrieves entry E) > >> Edit entry E using client B (client B should issue GET on entry E, but > >> if offline it will use its local store) > >> PUT entry E back to the server, without changing atom:updated (using > >> ETag; assume here that there is no conflict) > >> Sync with client A [1] > >> Go offline > >> Edit entry E with client A (client A will use its local store) [2] > >> Go online > >> PUT entry E back to the server (using ETag) [3] > >> > >> [1]: how can client A know about the changes made by B > >> > > > > When A tries to put it back, conflicts will have to be > > resolved. > > > Following the VCS comparison, AtomPP clients can't always implement > merge functionality (moreover, you first need to convert HTML, XHTML, > Markdown, Textile, etc. into a single markup language) and 999‰ cases I > talked about earlier would need user interaction. > Having an app:modified is a really simple solution for these annoyances, > and I think it hits the 80/20 mark. Again, I tend to think that this is an edge case and 80/20 is a long way off. > >> My opinion is that a protocol where client A would not be told that > >> entry E was changed by another client/user, such a protocol is buggy. > >> The bug is easy to fix… > >> > > > > What if A was your laptop at your house and when > > you went home after editing with B at work, your > > internet connection was down. Now you never had > > a chance to sych and you are right back in the > > same boat editing a "buggy" copy. All the > > timestamps in Switzerland wouldn't help you here. > > > How is this related to the AtomPP design? > > Even if using a VCS with optimistic locking, when your connection is > down, you won't be able to "check out" the current version of your files > and will degrade to editing an older version and resolve conflicts when > your connection is back up. > That is my point. It is going to happen. We have to be able to deal with conflicts (resolution or just warn "you are about to overwrite a change" or whatever) so modified buys us slightly better synchronization but I don't think it is enough to be worth it. IMHO. - Luke
