On 10/25/05, Thomas Broyer <[EMAIL PROTECTED]> wrote: > Luke Arno wrote: > > On 10/25/05, Thomas Broyer <[EMAIL PROTECTED]> wrote: > > > >> Luke Arno wrote: > >> > >>> Offline editing will require conflict resolution, regardless. > >>> > > > > I should have said, "unless you want to risk lost updates." > > > This is not only the case when editing offline, online editing also > require conflict resolution in a multi-user system.
Right. > >> 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. How conflicts are resolved is orthogonal to how conflicts are detected. > >> Prerquisits: Only one person can gain access to resources on your system: > >> you! > >> Scenario: "You've written an entry, then some minor spelling boo boo is > >> brought to your attention. you edit the entry, save it without bumping > >> atom:updated because you don't want to annoy your readers with every damn > >> little tweak. Later you want to add a significant update with the latest > >> news [,offline, with another AtomPP client] ... and your editor then > >> reverts the copy to the spell buggy version." > >> Then, at the time you get back online and save your entry, your editor > >> asks you to resolve conflicts. > >> User reaction: how can there be conflicts, no one else can gain access to > >> the entry but me!? Shouldn't I already have had the latest version instead > >> of the spell buggy one?! > >> > > > > Sorry. Your example does not say what client you > > are using when so I can't make sense of it. > > > > Did you mean this: > > > > You POST an entry from client A. > > You GET that entry to edit in client B. > > You change spelling and PUT without updating updated from B. > > You edit the entry offline from client A. > > > > If so, how did A know about the changes made from B? > > > 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. > [2]: if client A is not aware entry E has changed, you end up editing > the "spell buggy version"; if client A is aware of the change, > everything's OK. You edited E while off line. You may be editing a buggy version. Conflicts are rarely a big deal to resolve. I don't think this is worth introducing a timestamp. Have you used a version control system with optimistic locking? > [3]: if client A is not aware entry E has changed, you must resolve > conflicts (there _are_ conflicts here), and most likely you' have to > _manually_ resolve them; this wouldn't have been needed if client A were > told entry E had been modified by another client. (in other words, if > client A is aware of the change, everything's OK) This is not a big problem and there will be times when the user has not synched up anyway. I see what you are getting at but I do not think we need to be so paranoid about conflicts. I run into source code conflicts on a regular basis and it is no big deal. And proportionally it does not happen very much. Not nearly as much as most people seem to assume when they have not been using optimistic locking (VSS). > > 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. It is going to happen but less than you may think and is not going to be a huge deal to resolve when it does (9999 times out of 10,000 or so). > >> Moreover, why couldn't there be "light AtomPP clients" without conflict > >> resolution tool (e.g. diff between local and remote version in > >> side-by-side windows, ala WinMerge) to be used exclusively on mono-user > >> systems? > >> > > > > If so the users should be made aware of their risk of lost > > updates. > > > Off course! > I will refrain from making a joke about "off course" because I know that I would do much worse in French and it is probably just a typo anyway :) - Luke
