Re: [coldsync-hackers] Design logic of Sync conduits

[Marco van Beek <marco at 84andahalf dot com>]

> You assume that a user will *never* want to sync with
> the Palm desktop or at home or with a memory stick,
> etc...

Pretty much, yes! Since the fundamental reason for the project is to 
give users ALL of their information in a single system, going home and 
synchronising with the Palm desktop defeats the object anyway.

> You are going against "best practices" and you should
> be very careful.  Since all new records are going to
> be assigned an ID via the Palm OS, it ONLY guaranties
> an ID to be unique with respect to its own IDs.  What
> happens when Palm OS picks an ID your MySQL database
> generated?  Data loss?  Boom?

Somewhere I have seen a Palm field called LastUniqueID. If that can be 
read and/or written to, we should be able to tell if this is about to 
happen.

> There in lies the rub ... it is *not* MySQL's job but
> the device's job.  Do you have users on Palm OS 3, 4,
> and 5?  Do you have users on Palm mXXX, Clie,
> HandSpring, etc...?  Just "I haven't seen a problem"
> doesn't make good design.  It just may mean you are
> lucky ;-)

So far we have users with a Palm Vx, 2 x Palm 3x and one handspring. To 
be perfectly honest, I am primarily solving my own problem, that of 
wanting a proper server based multi-user solution to data storage and 
access for my business. Apart from some very expensive closed source 
solutions, I have found nothing out there that I would want to use, much 
less pay for. Coldsync was the trigger for the project as up until I 
started looking at it, we were just exporting the data as CSV and using 
 the file import facility in HotSync.

Because Coldsync can run as a daemon, it requires no local users, no 
local interface other than a cradle (and I do it via my Win98 desktop IR 
port and a VPN to the office).

> I hardly think a key with 1 integer vs. a key with 2
> integers complicates things at all.  If it does, just
> make the MySQL id a "long long" and shift the user id
> in front of the unique record ID.
>
> *If* you stay with the "change the ID" method, at
> least use something like 'DmSetRecordInfo' to change
> the ID and save the upload/delete/download step.

Thanks, I am not sure I have seen that method. I have been using the 
version of Coldsync that Debian installs (2.2.5) because I wanted to 
remain with easy to install packages as much as possible, I have missed 
out on a lot of useful tools, including the whole of ColdSync::PDB !!

I need to upgrade to the latest CVS stuff before I go much further. If 
(big IF) I can sort out changing id records in the palm without danger 
to data integrity (I have rolling hourly data backups as the development 
system is effectively live), which may require quite a few sanity checks 
(not least my own) before committing data, and I plan to stick with the 
standard apps (address, memo, tasks & datebook as they work already in 
fetch,dump mode, so I have a good understand of the data, and already 
have a backend that supports it).

The only way I can see a multiuser system working without being a 
complete nightmare is to use a field which is identical across all 
devices & databases. At least in the Address book there are custom 
fields that could be used (but the user can also alter them...), so if 
the id thing doesn't work, I don't know a simple way of doing it. Using 
a mixture of user-ids and record ids would work in a situation where we 
were only trying to sync with a single user/PDA's data.

I see the PDA's as a small part of a larger picture. If that picture 
means they can never sync with another system, they will have to live 
with it. All I can do is try and make sure that anything the Palm 
Desktop does is done better via the web interface or one of the other 
interfaces like LDAP.

Thanks for all the comments, suggestions, advice, examples, and watch 
this space. I will be back (If I haven't accidentally overwritten the 
mailing list email address!)

Regards,

Marco.


This message was sent through the coldsync-hackers mailing list.  To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body.  For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.