[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [coldsync-hackers] Snapshot: 2.0.0
On Fri, Feb 23, 2001 at 04:58:53PM -0500, JD Smith wrote:
> Andrew wrote:
> 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.
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.
> 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.
If syncing is fast enough, you won't care whether you're
syncing one database or all of them. Take care of the speed problem
above, and the rest will take care of itself.
Just kidding...
Seriously, though, this seems useful enough, but since it's
your itch, I'm going to let you scratch it. Send me a patch.
> 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,
Rather than adding a new keyword to the config file syntax, I
think it might be cleaner to just change the command line syntax from
coldsync -ms
to
coldsync -ms [database ...]
Thus, if you run it as 'coldsync -ms AddressDB', it would run a sync
as normal, but only for the AddressDB database.
"Normal sync" could include a Fetch conduit that checks for
the existence of ~/address-I-just-wrote-down , parses it, and adds it
to ~/.palm/backup/AddressDB.pdb .
--
Andrew Arensburger This message *does* represent the
arensb@ooblick.com views of ooblick.com
Crime doesn't pay, but at least you're your own boss.
--
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.