Re: [coldsync-hackers] Hotsync proxy to coldsync ...

[Andrew Arensburger <arensb+CShackers@ooblick.com>]

On Sat, Nov 03, 2001 at 02:20:08PM +0100, Johan Van den Brande wrote:
> It works!

	Cool!

> > But if you're going to be doing that anyway, why not keep your life
> > simple and write a conduit that Does The Right Thing in the first
> > place? That is, if you want to sync your Address Book with the
> > corporate LDAP server, don't forward it to ColdSync on a remote
> > machine, talk to the LDAP server directly.
> 
> The deeper motiviation for this to happen is to write an OSS sync
> server, like
> the Hotsync server from Palm. What I want to limit is the need to
> completely
> rewrite conduits on the server side. There are already usefull Palm::PDB
> codecs
> for Memo, Doc, Timesheet ( ;-) ) ... etc ... 

	You mean, something where you have PDBs on two machines, and
you want to sync them with each other, without necessarily having an
actual Palm involved? Yes, this could be rather useful in a number of
situations (I, for one, would like to be able to sync either at work
or at home, and have the home and work machines work out the details
amongst themselves).

	One way to do this would be to have the two hosts exchange md5
signatures for their respective PDBs. If the signatures match, no
further syncing is required.
	If they don't match, the obvious thing to do would be to
exchange md5 signatures for the records themselves. However, I've seen
PDBs with over a thousand records. Usually only a handful of these
will have changed at any one time. So perhaps a better approach would
be to split the PDB up into eight sections, and calculate the md5
checksum for each such section. That way, the two hosts can quickly
verify that large chunks of the PDB match and need not be synced. Once
a differing eighth is found, it can be split up into eight more pieces
recursively, and so forth.
	Or maybe you can look at cvsup and similar protocols to see
what they do. I suspect this is a solved problem; it's just a matter
of finding the solution.

> Another route I'm thinkering about is using a generic hotsync conduit
> that forwards
> the PDB structure (categories etc ...) via a protocol ( probably XML-RPC
> over HTTP)
> to a server application that reconstructs the behaviour of COldsync, ie
> to keep the
> conduits compatible ... I'm thinking about using apache as a middle-ware
> core (message
> broker ) and writing it in the mod_perl framework .. ie a sort of
> mod_palmsync kind
> of thingy.

	I'm a bit uncomfortable with using Apache (or any http daemon)
for this. From a security standpoint, it's best to restrict the number
of services on any given server. So if you make this part of Apache,
then your server is vulnerable not only to ColdSync bugs, but also to
Apache bugs.
	Of course, if your server is going to do both anyway, then
it might be desirable to integrate this into Apache. And, of course,
if you're already comfortable with extending Apache, then start with
that (optimize for developer time), but if you could keep the code
modular enough that it can easily be integrated into ColdSync or
turned into a standalone daemon, that'd be dandy.

> Do you know of any GUI projects for coldsync? They all seem to be build
> arounf pilot-link, but
> pilot-link is a bit archaic IMHO ...

	Sorry, no. I'm not really sure what a ColdSync GUI would look
like, anyway.
	One thing on the "to do" list is to write a pilot-link
compatibility library so that projects like JPilot can link against
libpconn without any change to the source, but that's mostly in the
conceptual phase right now.
	Another issue is that the format of .coldsyncrc does not
really lend itself easily to being parsed by a program (whitespace
doesn't matter, it uses ';' as statement separators, etc.). A
.ini-style configuration file would be much easier to read and write,
albeit perhaps at some cost in flexibility. You could have
	[Listen]
	Type=serial
	Protocol=full
	Device=/dev/cuaa2
	[PDA]
	Name=My M505
	Serial=189X7M27GA63-N
	Directory=/homes/arensb/.m505
	[Conduit]
	Flavor=fetch
	Flavor=dump
	Path=/usr/local/libexec/some-conduit
	...
ColdSync could then check for the existence of ~/.coldsynrc and use
that if it exists; if not, check for ~/.coldsync.ini and use that.

	Finally, it would be really nice if the GUI could display
what's going on during the sync (show completion bars and other pretty
widgets).
	The problems here are that a) ColdSync might be running in
daemon mode, out of the user's control, and b) the GUI may or may not
be running at any given moment (and in particular, the GUI may dump
core; but this should not affect the daemon).
	In a simple world, ColdSync could simply send out status
information in broadcast UDP datagrams. Any client that is interested
in these could listen for these. If there are no listening clients, or
if some of them die horrible deaths, the broadcasting daemon wouldn't
care or even notice.
	However, we do not live in this simple world, and I'd rather
not broadcast such personal information over a possibly-insecure
network. If it were possible to broadcast information over a Unix
socket, that would be great, since you could use standard Unix file
protection to restrict access, and the information wouldn't be going
out over the network. Unfortunately, I never managed to get this to
work.

-- 
Andrew Arensburger                      This message *does* represent the
arensb@ooblick.com                      views of ooblick.com
	 Send $20 and I will double your IQ or no money back.
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.