Re: [coldsync-hackers] Reporting conduit errors

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

On Sat, Sep 20, 2003 at 09:45:38PM -0400, Christophe Beauregard wrote:
> On Thursday 18 September 2003 19:14, Andrew Arensburger wrote:
> > 	So I suppose the most sensible thing to do would be to collect
> > conduits' error messages during Install and Fetch conduits into a
> > variable-sized buffer, and upload that buffer to the PDA's log in the
> > initial part of the "main" sync.
> 
> With the current implementation, is there any strong reason (aside from the 
> potential to add non-PDA driven behaviour for fetch conduits) why fetch and 
> install conduits couldn't just be implemented as "special" sync conduits 
> and directly use dlp_AddSyncLogEntry()? Seems less painful than adding 
> buffering.

	Currently, the log on the Palm is just a series of lines of
the form
	<database-name>: <status>
Having the main ColdSync binary collect all of the messages from all
of the conduits and log them in a consistent format would please my
sense of esthetics.

[...]
> > As for errors during Dump conduits,
> > perhaps the only reasonable thing to do is to mail them to the user.
> 
> Works for crond and friends. Would also work for non-hotsync fetch. But it 
> might not be the desired semantics. A user might be a little ticked when 
> they find that their urgent "I'm gonna be 20 minutes late, don't leave 
> without me" e-mail (sent via, say, the send-mail dump conduit) didn't 
> actually get sent before they grabbed the PDA and headed for the door. 
> Okay, "urgent e-mail" is an oxymoron, but you get the point.

	True, this is a limitation of the current implementation
(rather, the broader problem is that you don't get any feedback from
anything but Sync conduits.

> > 	Any thoughts?
> 
> It's almost like you need to create a new classification scheme to properly 
> handle this. Something like connected vs unconnected conduits. sync 
> conduits are obviously connected. fetch conduits (currently) run when a PDA 
> is connected but don't have the same infrastructure as a sync conduit and 
> so are unconnected. Ditto for install.
> 
> dump conduits are definitely unconnected. Since that unconnected state is 
> fundamentally a performance hack of sorts (for user and battery time), 

	I wouldn't call it hack. Rather, it's an optimization for user
time: a Dump conduit can potentially run for a long time, but the user
can just grab ver Palm and walk away, without having to wait for the
conduits to finish running.

> there's probably no real reason why some dump conduits couldn't just set a 
> flag and hang on to the PDA until they're done.
> 
> BUT...
> 
> A connected dump conduit would be essentially a sync conduit that runs after 
> all the other sync conduits normally run. A connected fetch is also similar 
> in that it just runs before the usual syncs. sync conduits aren't (IMHO) 
> any harder to write than a fetch or dump conduit if all you're doing is 
> changing an on-disk database. So all this discussion just seems to boil 
> down to 1) write sync conduits 2) order them appropriately in the 
> configuration file.

	It's clear that a Sync conduit can do anything that any other
conduit can do. The reason there are Fetch and Dump conduits in the
first place is that they're significantly easier to write than Sync
conduits, in the general case. Thus, they optimize for conduit
developer time (which is less important than user time, but more
important than ColdSync developer time).
	But there might be a way to have everything: if you've worked
with the C++ STL, you're familiar with the way that it uses objects
not just for data structures, but also for algorithms.
	It should be possible to do the same thing here: write a Perl
module that implements the generic sync, with all of its complications
and flourishes. It should use methods for most things, e.g., reading
the on-disk PDB, parsing a raw record, comparing two records to see if
they're identical, and so forth. Throw in some Emacs-like hooks for
doing things before and after the sync.
	This way, you can implement a "connected Dump" conduit by
subclassing this generic conduit object, but redefining the post-sync
hook; or implement a Fetch conduit by providing your own pre-sync
hook.
	The idea is an old one: simple things should be simple, and
complex things should be possible. I think a conduit object like the
above would do that, but I haven't written one.

-- 
Andrew Arensburger                      This message *does* represent the
arensb@ooblick.com                      views of ooblick.com
			  You have new spam.
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.