Re: [coldsync-hackers] Design logic of Sync conduits

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

On Wed, Mar 03, 2004 at 10:30:32AM +0100, Janssen, B.J. wrote:
> I just wrote a Fetch/Dump Conduit combination using the Datebook Perl 
>>Module and would like to add something like this (sshkey identificatio
>>n) to my conduit. How can I do something like that? Can I get informat
>>ion from another prc file while I'm fetching from the Datebook?

	In the current implementation, coldsync is connected to the
PDA when running Fetch conduits. However, conceptually, it need not
be. The idea is that a Fetch conduit gathers information from
disparate sources and writes a file in ~/.palm/backup/Foo.pdb the way
it ought to be. Then the sync conduit (usually the default conduit)
ensures that Foo.pdb is the same on disk and on the PDA.
	In other words, you don't need the PDA in order to run the
Fetch conduits. You could, for instance, have a conduit that retrieves
news headlines from a dozen web sites; since this takes several
minutes, you would have it run early in the morning each day. Then,
when you sync, the .pdb file on disk would already have all the
required information.

	What you're trying to do here is authentication. So you need
to have the PDA connected. And also, presumably you only want to
exchange data with the PDA if it is the correct one. This brings up a
whole set of problems.
	Since the PDA needs to be connected, you need to do the
authentication in a Sync conduit. Of course, if the authentication
fails, you don't want to send sensitive data to the PDA.
	This leads to the next problem: unless I've missed something,
there's no way to connect conduits in the .coldsyncrc: you can't say
"run conduit B only if conduit A ran successfully" or "if conduit C
failed, abort."
	For now, the best I can suggest is that your Fetch conduit
should create two versions of the .pdb file: one with sensitive data
and one without. And also a Sync conduit that downloads the
authentication key from the PDA and checks whether it's okay. If it's
okay, the Sync conduit copies the sensitive data to
~/.palm/backup/Datebook.pdb, then allows the generic conduit to take
over. If the authentication fails, then it removes all sensitive data
from ~/.palm/backup/Datebook.pdb, and lets the generic conduit to take
over.

	In the long term, a better solution might be to improve flow
control in .coldsyncrc. Something like:
	conduit Fetch "Get dates" {
		# Fetch datebook data
		path: /usr/local/bin/fetchdates;
		type: date/*;
	}
	conduit Dump "Dump dates" {
		require: "Get dates";
		path: /usr/local/bin/dumpdates;
		type: date/*;
	}
	conduit Sync "Authenticate" {
		path: /usr/local/bin/authenticate;
		abort-on-fail;
	}
	conduit Sync {
		type: none;
		path: [generic];
		require: "Authenticate";
	}

Here, conduits have names. The "Dump dates" conduit would run only if
the "Get dates" conduit exited cleanly (one could also have
		require: "Get dates" fail;
to mean "run this conduit only if 'Get dates' failed"; one could also
specify particular exit codes).
	The "Authenticate" conduit has an "abort-on-fail" flag, which
would cause coldsync to abort if the conduit fails. (The syntax could
be better; there might be other reasons to abort.)
	(And yes, the 'require: "Authenticate";' command is
redundant.)
	The easiest way to implement this might be to add a field to
the internal conduit queue, to store the exit status of each conduit
(or -1 if it has not yet been run).
	One limitation of the above is if you have something like:

	conduit Fetch "Generic fetch" {
		path: /usr/local/bin/genericfetch;
		type: */*;
	}
	conduit Dump "Generic dump" {
		require: "Generic fetch";
		type: */*;
		path: /usr/local/bin/genericdump;
	}

then the "require" line effectively asks, "has 'Generic fetch' _ever_
run successfully?", rather than "has 'Generic fetch' run correctly _on
the current database_?".

	This sort of linking would allow you to have a single generic
"Authenticate" conduit that protects a whole range of other conduits.

	Okay, I've gone on long enough. Does anyone have any thoughts?

-- 
Andrew Arensburger                      This message *does* represent the
arensb@ooblick.com                      views of ooblick.com
		    Don't laugh. It could happen.
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.