Re: [coldsync-hackers] Snapshot: 2.0.0

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

On Sun, Feb 25, 2001 at 03:22:42PM -0500, John-David Smith wrote:
> Andrew Arensburger wrote:
> >         I've just looked at the diffs between 1.4.4 and 1.5.3, and the
> > only thing that's changed that even remotely looks as if it might have
> > anything to do with this problem is that in
> > libpconn/PConnection_serial.c,
> > 
> >                 sleep(1);
> > 
> > now says
> >         #if defined(__FreeBSD__)
> >                 sleep(1);
> >         #endif
> > 
> > You may want to try reinstating the sleep(1) and see if that helps.
> > 
> >         Though another thing that occurs to me is this: there are
> > several instances of tcsetattr(TCSANOW). Perhaps those need to be
> > changed to use TCSADRAIN or TCSAFLUSH. If you could play around with
> > this and see what (if anything) helps, I'd appreciate it.
> >         Obviously, if the sleep(1) proves unnecessary, that'd be best.
> 
> Well, I took a look.  You can make 1.5.3 act like 1.4.4 by reinstating the
> sleep(), the only real change.  This doesn't gaurantee it will work at a given
> speed... you just make it past the ACK Timeout phase, but you may then get Bad
> CRC's... seems to depend on the hardware.  The TCSANOW setting doesn't seem to
> matter.  

	$#@!$#/$%**!! piece of... garrgh... GAH!
	You know, I'm starting to really hate serial lines and their
idiosyncracies. This would be so much easier to maintain if I just
stopped trying to support
	- Serial connections
	- USB connections
	- Network connections
	- Non-Unix OSes
	- Non-BSD Unices
	- BSD Unices
	- Palm stuff

> This is a long way from solving the problem though.  2.0.0 has many more changes
> in PConnection_serial.c and associated files, and even with sleep(1) reinstated,
> still hangs up on ACK Timeouts.  Interestingly, it seems to read a PADP command
> with success:

	Yeah. "ACK Timeout" is a problem going the other way: the
desktop sends a PADP command to the Palm, and times out waiting for an
ACK.

> Once the WAKEUP packet is received and acknowledged, the very next thing sent is
> different between the two versions:
[...]
> I.e. DLPCMD_ReadSysInfo in the good old days.  DLPCMD_ReadUserInfo now. Probably
> reflects the new emphasis on getting the user name right from the get go
> (anti-bargle bug).  Should it matter that the serial number (and sysinfo) is
> read after the username now?  I don't see why, unless the ROM version from
> SysInfo is being used to set up other connection parameters.  Any thoughts? 

	In earlier versions, functions in src/coldsync.c would have to
explicitly call DLP_*() functions to request information from the
Palm. There were a lot of steps that had to be performed in a
particular order, which got rather confusing. The fact that everything
was always fetched before syncing anything also led to ColdSync being
perceived as being slow.
	Now, this has been abstracted into the palm_*() functions (see
"src/palm.h" and "src/palm.c"). Thus, if you want to get the user name
from the Palm, you just call palm_username(palm), which either returns
the username if it has already been downloaded, or else does all the
necessary groundwork, then downloads the user info and returns the
username.
	If you RTFS, you might see similarities between "palm.c" and a
Makefile.

-- 
Andrew Arensburger                      This message *does* represent the
arensb@ooblick.com                      views of ooblick.com
In the beginning there was nothing, and God said "Let there be light."
	  And there was still nothing, but you could see it.

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