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)
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)
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.
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.
--
Thomas Broyer
