[coldsync-hackers] Non-PalmOS PDA Syncing (was Zaurus syncing)

["Brian Johnson" <bjohnson at jecinc dot on.ca>]

I considered something like that but decided that the sync would likely run faster
(and that is a definite advantage) if the bulk of the processing were done on the
desktop/server where processing power isn't limited to fitting in a pocket

Reconsider the concept I suggested, we need not actually touch the coldsync code -
just the conduits

The entire connection and transfer system would be done with standard network tools
(tcp/ip, dhcp, dns, ssh and scp).  If the server had internet connection, the Z
could sync from anywhere it could get internet connection (NICE!!!) including LAN,
modem ppp calls, VPN and also including through wireless networks via compact flash
802.11 cards

The connection to an IP network would be done by the Zaurus, then using Coldsync
terminology, scp the Z files, do the fetch conduit, do the sync conduit, scp files
back to Z, do the dump conduit

So Z connects to TCP/IP network (there are already a variety of ways to do this),
run a script that connects via ssh to the server (this too is old hat) and runs a
script or program on the server (and feed it the current IP address of the Z) for
the server to connect back via scp to get the Z files, run the sync conduit
software, and scp the files back.

The server software would also parse the Z files and respond to conduit record calls
to match those of the Palm modules (might be some inconsistencies here but I can't
tell without getting into it)


Perhaps I'm wrong, but IMO the coldsync code currently does three things: 1. handle
data connection and transfer 2. parse the config files 3. call the conduits

One thing that it does that my proposed system doesn't do is perform record by
record updates (coldsync doesn't transfer the entire pdb does it? - maybe it does?)

Here are my main points:
1. if we can modify coldsync to maybe accept a system call to do 2 and 3 from above
and
2. we can make modules that duplicate the function of the Palm modules but for a
different data format

then
A. any coldsync conduits that use the Palm modules would also handle the data from
the Z (or any other PIM that uses the same XML data file format)
B. the same system could be used for any other device that uses ssh and scp and the
same xml format (for any other format only the mimiced Palm modules would have to be
created)
C other devices using other connection protocols could write a daemon to call
coldsync to do conduit driving


Essentially, what I am saying is ... separate coldsync into two components, the
connection and transfer system, and the config file parsing - conduit driving portion

Combined with replacement Palm modules to parse the pda data files (actually it
would be best if they weren't a replacement, that they could live side by side),
coldsync changes from a Palm sync package to a device sync system.  Adaptable to any
device (including pocket pcs) and adaptable to any data format for which translator
modules can be written

I don't consider that a tumor ... I consider that AN AMAZING IMPROVEMENT!!! - not
available with any other software


Now everybody, poke holes in this concept, I want to see how difficult it would be
to implement

I would also REALLY like to hear the thoughts from the Coldsync developers on this






Justin C. Ferguson (jferg+coldsync-hackers@lusars.net) wrote*:
>
>When last we left our heros, they were speaking of:
>> they already are - kind of), interface modules could be created to mimic
>> the Palm perl module's output to feed to the conduits
>>
>> Therefore, the Coldsync Palm conduits would work with the Zaurus files too.
>> In an office supporting both devices, this common conduit mechanism would
>> simplify conduit upgrades - wouldn't it?
>
>	After posting my response to your message yesterday, I had some
>further thoughts on ways that a Z could be made to talk to coldsync/Palm
>conduits in general.  My thoughts are basically this:
>
>	1. The (IMHO) least elegant method is to hack a tumor onto the side
>of coldsync that will sync with a Z, basically independant of most of the
>code for palm.  I don't like this idea a lot.
>
>	2. The second least elegant method is to write a translator that will
>pull the databases off of the Z, convert them to Palm format, and then use
>coldsync to do the sync thing.
>
>	3. The most elegant method (again, IMHO) would write a module which
>would actually run on the Z which would speak the Netsync protocol, and be
>able to read and write the Z's XML files.  This way, no matter how the Z was
>connected to the net, it could sync with Palm Desktop or coldsync.
>
>	I'm planning on making an attempt at coding up #3 at some point in the
>near future.  I'll keep you posted.
>
>								JF
>
>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.
>

-- 
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.