Re: [coldsync-hackers] Snapshot: 2.0.0

[JD Smith <jdsmith@astro.cornell.edu>]

I sent this before and it did not make it through.  Apologies if you've
received more than one copy.  One more try...

Andrew wrote:
> > Still doesn't fix the ACK Timeout problem or allow the highest serial
> > speed for me... sigh.  Could we just reinstate the serial code from the
> > last version that worked well (circa 1.5.x)?  Are others having this
> > problem?
> 
>         For what it's worth, I tried ColdSync 2.0.0 yesterday under
> Linux (Redhat 6.2 with Linux 2.4.1) and a Palm III on /dev/ttyS0. I
> wasn't able to sync at all at 57600 bps: packets would go out, but
> nothing would come in.
>         At 38400 bps, things worked. There were a number of "Bad CRC"
> messages, but all in all, I was able to sync. So I really don't know
> what the problem might be. I've read Stevens until I got blue in the
> face, and this problem only crops up under Linux, as far as I've
> heard. So I don't know what to do about it.

I went back through all my versions of coldsync resident, and tried them
out, (RH6.2, Kernel 2.2.16 -- so it's not a 2.4.x issue!) using exactly
the same .coldsyncrc file.  Only at Coldsync version 1.4.4a was I able
to get the sync to work as I remember it used to: at 115200 baud, no ACK
timeouts, and *fast*.  By the way the "a" was for the patch I submitted
long ago to do "install-only" ala "pilot-xfer -i" -- i.e. unrelated to
serial I/O.  The next version I have is 1.5.3, which exhibits the same
behaviour as current versions. Somewhere between the two something must
have happened to the I/O code.  

> > 1.  There's no convenient way to run a conduit which is not associated
> > with a given database.  I ended up kludging it to run with the Datebook
> > database, with all the overhead of reading the AppInfoBlock, etc.  It
> > would be nice if you could run any given conduit always, without
> > specifically finding it on a given database's list.
> 
>         Yeah. Any suggestions on how to do this? How about
> 
>         conduit sync {
>                 type: none;
>                 path: /usr/local/bin/settime;
>         }
> 

I like this.  Maybe a mechanism to describe *when* to execute such a
free agent (e.g., type: first,type: last).  

Another addition which seems well within the expressive power of the
current rc file structure is the ability to connect and sync one and
only one database.  I use this paradigm all the time... somebody is
telling me their address.  Rather than entering it on the palm, I
quickly key it into a text file, and use a special purpose pilot-link
tool "pilot-addresses" to quickly add it.  Coldsync could extend this
functionality to all databases, and do it more cleanly.  

Ideally, a record (like the new address) is first added to the database
in the backup directory, and then that backup is synced by itself. 
Since coldsync (and not pilot-link) can do Fast syncs, this is the exact
thing you want.  It integrates with any other tool which happens to be
modifying that database, etc.  The only limit is coldsync's overhead. 
If you added a control word, such as "single", to the rc file syntax,
and if you act on that control by skipping all the usual "download the
list of databases, etc., etc.", and go directly to syncing that specific
database, you'd be able to easily create simple one-shot features like
this.  Slap a piece of text into your memo database.  Add a quick
appointment as you head out the door.  Etc.  Etc.  Maybe something like
coldsync "Datebook" would parse the argument as a single (or multiple)
database to concentrate all attentions on.

Just my daily musing,

JD

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