Re: [coldsync-hackers] Reporting conduit errors

[Christophe Beauregard <christophe dot beauregard at sympatico.ca>]

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.

In the case of a fetch conduit running from something other than a hotsync 
(i.e. from crond or a web watcher) you'd have to come up with some way to 
persist error messages for when a hotsync was ready. I'd handle all the 
database race conditions before I bothered to look at that particular 
issue.

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

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

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