RE: [coldsync-hackers] modem sync success -- details for contribution

["John Joseph Roets" <jjr@sunflower.com>]

> > This only requires disabling 2 lines within
> PConnection_serial.c
>
> 	Which two lines have you deleted?

Lines 500-501.

> 	If it's just a matter of deleting two lines, send the patch to
> this list, since I'm not sure when I'll be able to put out a new
> snapshot.

We would need only delete lines 499-501.  But, the complete patch would depend
upon that which follows.

> > I also need to know if there would be a preferred way to handle
> this.  That is,
> > should another LISTEN_ type be added (e.g. LISTEN_MODEM invoked by <-t
> > serialmodem> perhaps)?  And if so, what would be the preferred method for
> > passing the LISTEN_ type to PConnection_serial.c?
>
> 	I'm not sure. That depends on what you needed to do.
> 	If you've set up a daemon that's started at boot time, listens
> on the modem device, and knows how to talk to a modem, then that's
> overkill and contrary to The Unix Way (tm). It'd be better to let
> 'getty' answer the phone and run ColdSync instead of a shell. This is,
> I believe, the way that PPP usually works.

I've tried this multitudinous ways, and could not even get close to mgetty
properly connecting ColdSync.
I do know that mgetty did properly launch ColdSync to listen on the required
port, yet ColdSync would never receive any data.  Nor would any other app that
mgetty launched (I tried a few test scripts if you recall).
I rather ran ColdSync in its daemon mode from within /etc/inittab as described
within README.daemon:
P0:2345:respawn:/usr/local/bin/coldsync -z -l /usr/local/etc/test.log -t
serial -md ttyS0
This works perfectly, and I don't need to worry about its dependability, i.e. it
is VERY dependable.

> 	Having said this, once ColdSync has a connection to the Palm
> over a serial line, presumably it just needs to do a standard serial
> sync. Ideally, it shouldn't matter whether this happens over a serial
> line connected to a Palm, or a serial line connected to a modem. So in
> an ideal world, it should Just Work.

The following lines (499-501) cause garbled data to make it to ColdSync, which
then fails.  The modem does not need the initial handshaking to decide upon a
speed, as does the cradle:
	/* Set initial rate. 9600 bps required for handshaking */
	cfsetispeed(&term, B9600);
	cfsetospeed(&term, B9600);

> 	As for LISTEN_*, the PConnection stuff in libpconn is really a
> class (in the object-oriented sense): PConnection is an abstract class
> that specifies an API for talking to a Palm, and PConnection_serial is
> a more specific subclass that knows how to talk to Palms over a serial
> line. When you specify a listen type with "-t", you're really choosing
> the specific subclass to use. Hence, there's no need to pass the
> LISTEN_* type to PConnection_serial.c, since by the time you're in
> there, you already know that the listen type is "serial" (see
> "libpconn/PConnection.c").
> 	Does this make sense?

Right.  I originally considered a completely new class for the modem connect,
but wonder about the later maintenance issues of two classes of completely
duplicated code (but for the 2 lines).

What do you think?  Is there any other visibility of the listen type within this
class?

Thanks.


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