Hi,

I'm currently working on conflict resolution during sync, i.e. what happens if 
you review the same card both on your desktop and on your phone. Obviously, 
one of the copies of the database needs to take precedence then.

I originally planned on bringing the 2 databases back in sync by having a 
nifty little scheme to send across just the information needed to undo the 
events that need to be undone.

However, this turns out to be impossible with the current database layout, 
because of the fact that a user can sync between more than 2 partners, e.g. a 
phone, a desktop and a webserver. (Without getting too technical, it's 
possible that the events that need to be undone are no longer the last events 
in the database and are therefore impossible to find, except by adding a UUID 
to each event which would increase the size and processing power 
tremendously.)

So, I resorted to sending across the entire database in order to bring the 2 
copies back in sync. Takes more time, but given the fact that conflicts should 
be rare, this is not the worst of my worries. 

What is slightly more worrying though, is that in order for the client to send 
its database to the server, the client database should contain all the info 
that is also present in the server database. This will certainly not be true 
for card-only based clients like the iPhone and the Android/Java ones, but 
also for clients based on libmnemosyne (like Windows Mobile or Maemo), this 
could be an issue, as the client could have chosen not to hang on to all old 
history because of size constraints.

So, the upshot is that, apart from libmnemosyne clients which keep the full 
database, upon conflict you will only be able to revert to the version on the 
server, and not the version on your phone...

A bit unfortunate, but hopefully this is not a huge problem since conflicts 
should be rather rare and easy to avoid with some attention.

Just to reassure you, the common case of doing reviews on your phone while 
adding cards on your desktop does not result in a conflict; the sync algorithm 
is entirely bidirectional.

Feedback welcome!

Peter 

-- 
You received this message because you are subscribed to the Google Groups 
"mnemosyne-proj-users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/mnemosyne-proj-users?hl=en.

Reply via email to