-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David C. Rankin wrote:

On Tuesday 01 September 2009 04:58:10 am G T Smith wrote:

...

Take a look at...

http://www.funambol.com/

But beware, funambol can have the nasty side effect of duplicating contacts due to the way it marks which contacts have been sync'ed causing either the phone or computer to reload a fresh set the next time it is connected resulting in 2 sets of the same contacts being present.

This is a common problem with other SyncML solutions. Data should be synchronised by date stamp (not contents), and there are all sorts ways this can go wrong. If server and client have different time stamps on data such duplication can occur, this should not happen (IIRC synchronisation date stamp is fixed for a synchronisation operation regardless of any latency in that operation). For funambol, this is most likely some sort of client issue which can be difficult to resolve in the server connector, though a bug in the connector code for a particular client could cause the problem, (or a possibly a missmatch between client and server connector). (Funambol uses connectors to handle the translation between a client and the backend database). - -- ============================================================================== I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone. Bjarne Stroustrup ============================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkqeOSwACgkQasN0sSnLmgJAfwCgtbnL1Gktp8o7Y0oZhmOonWuG F+4AoKZurPuEvq83IdchBVjZDHFoSy0e =qRuc -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Tauno Williams wrote:

...

...

But beware, funambol can have the nasty side effect of duplicating contacts due to the way it marks which contacts have been sync'ed causing either the phone or computer to reload a fresh set the next time it is connected resulting in 2 sets of the same contacts being present. This is a common problem with other SyncML solutions. Data should be synchronised by date stamp (not contents),

Absolutely not, never. Timestamps are a terrible way to syncronize. Objects should be versioned so changes can be detected easily; most groupware servers [AFAIK, OGo does] support versioning.

Hmm.. someone is making the assumption of a one to one relationship and continuous connection here. This could fall apart quite quickly in other scenarios. Non date related version information generated on unconnected devices would be unreliable as an indicator of which version was the most recent for basic data synchronisation purposes. According to the OMA DS SyncML spec each sychronisation session should be logged according to client/device and a time stamp. In certain SyncML synchronisation modes this can be used to determine which records need to be sent to a particular device. and whether synchronisation should take place at all (c.f. OMA-TS-DS_Protocol_V1_2_1-20070810-A; DS Protocol, BTW I have not checked whether this reference has been updated). It is not quite data time stamping but is effectively equivalent in function in that it establishes a time line. This is independent of any groupware product in use. Remember the protocol is designed to synchronise between computing devices and mobile devices over relatively slow and unreliable data links, so it needs to also robustly handle failed syncs.

I believe duplication is not primarily a bug in Funambol but in [possibly various] backends. I haven't seen duplication using the GroupDAV connector.

I am not certain WebDAV === SyncML. They may overlap but SyncML is a industry backed mobile phone standard, WebDAV does not quite fit this criterion.

I don't know if the LDAP backend uses it but there is a last-modified operational attribute in most [all?] DSAs. If not used as a timestamp but just as a key it should be a reliable form of change-detected. For LDAP it would seem the DN would be a stable primary key for a contact.

SyncML transmits data in an XML based syntax where the data item format is {i;data} where i is a data item ID and data is usually data in vCard or iCal format. A table of local and remote IDs per client and synchronisation status is also maintained , where local ID is (usually) the record ID in the local DS database, the client is responsible for allocating its data IDs. It is a lot more complicated than this but that is a crude summary. What I would expect for funambol is that there is a special LDAP client connector, which performs ID mapping and synchronises the local DS database with LDAP at a given interval. BTW An accurate DS (of which LDAP is subset) usually requires time synchronised replication of some sort, I know NDS does and AD I think does something similar. A DS requires not only a knowledge of what events take place, but when changes take place. (I last looked at openLDAP about 18 months ago and felt that was a bit limited then, things may have changed since). I think we have wondered well off topic here but some off the assumptions made here needed to be challenged. - -- ============================================================================== I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone. Bjarne Stroustrup ============================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkqfpKQACgkQasN0sSnLmgKDAACg9azc1NfHH8M5JZA0hKL/E+g7 aD4AniUy+fKyRP1bcAqX4LZmF4EKL98P =tbdc -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org