Re: [coldsync-hackers] Coldsync Client program

[Andrew Arensburger <arensb+CShackers at ooblick dot com>]

On Fri, 28 May 2004, Marco van Beek wrote:
> On the workstation would be another Coldsync daemon. This would would be
> running on a local port / cradle, but it would look up the "primary pc"
> record in the palm, and set up a network sync directly to the Coldsync
> Server. In an ideal world, I would be able to drop my PDA into any of
> the workstation cradles and get a sync, as this would allow for hotdesking.

	Take a look at the "forward" directive in .coldsyncrc . In
particular, according to the comments in lexer.l,
	forward: *;
means to forward the connection to wherever the Palm says.
	Presumably the client machine could run coldsync with a
/usr/local/etc/palms that contains
	*|*|*|*|*|/etc/coldsyncrc.forward-only

and /etc/coldsyncrc.forward-only would contain

	pda {
		forward: *;
	}

or something like it.

> What would be really neat is if the client Coldsync daemon could run via
> SSH and could be set up with private keys stored in a preferences file
> in the PDA (something similar has been mentioned on this list to improve
>   the underlying security of the sync process). This means that I could
> sync from outside my network simply by having an Internet accessible ssh
> server.

	Another possibility would be to have the client connect to the
server using its own key, not the PDA's.
	That is, if the intent is to have a minimally-"thin" client, that
merely allows the real server to reach out and use the cradle remotely,
then the client merely needs to prove to the server that it is a known
client; the server can deal with figuring out whether the PDA is really
the one that it claims to be.
	Does this make sense?

> And I guess if the Coldsync client program is written in Perl, there is
> a good chance it could get ported to other platforms without having a
> major re-write of the server based code, which means Windows and MacOSX
> become natural extensions of the system.

	I'm not sure how much you'd gain by writing this stuff in Perl.
For one thing, the existing C code already contains an implementation of a
bunch of stuff, including the various protocols involved in syncing. IMHO
it's good thing to continue using this. If the core code changes, you only
have to fix it in one place, rather than two.
	And AFAIK ColdSync is fairly portable already. Yes, it's
Unix-centric, but these days MacOS is Unix, so that's okay. That leaves
Windows as the main non-Unix platform. I don't know how hard it is to port
software between Windows and Unix, though there are reports of people
successfully building ColdSync out of the box under Cygwin. I'm not sure
where this leaves us. I guess it boils down to whether it's easier to
rewrite the necessary bits in Perl, or to port existing C code to Windows.
(But FWIW, IMHO spending time on writing portable code is a good
investment of time.)

-- 
Andrew Arensburger                      Actually, these _do_ represent the
arensb@ooblick.com                      opinions of ooblick.com!
                        Generic Tagline V 6.01
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.