Re: [coldsync-hackers] Writing conduits that read more then one DB.

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

On Wed, 4 Jun 2003, Izzy Blacklock wrote:
> WARNING:  A perlmonk I am not.  This is my first go at writing anything
> serious in Perl, so go easy on me! :)

	See http://www.ooblick.com/text/perl/, if I may be forgiven some
shameless self-advertising.

> What I'm trying to do is write a new conduit for Titrax.
[snip description]
> Obviousely this means I need to look for data in 4 sources.  At present, I'm
> not too concerned with the data in TitraxDataDB.pdb.  The logs held either in
> the datebook or TitraxNotesDB are what's important.  The TitraxNameDB is also
> important since it holds the project names as they appear in the Datebooks
> description field.  Also, the TitraxNoteDB is cross indexed with it.  ie, the
> project name for record 5 in the noteDB is record 5 in the NameDB.  The three
> databases created by Titrax all have creator ttrx, and types of data, name,
> or note.
>
> What I need to do is build a conduit that will read the TitraxNameDB, then
> check for notes in TitraxNoteDB and look for Databook records that have
> descriptions matching the TitraxNameDB entries.  My first message questioned
> whether it was possible to pass more then one InputDB header entry.  I
> suspect this isn't possible,

	Correct.

> and the better solution would be to pass
> arguments with the names of the extra pdb files to check.

	Also correct.

> I'm thinking of building my conduit to use a config like this:
>
>    conduit dump {
>                    path: /path/to/conduit/titrax;
>                    type: ttrx/name;
>                arguments:
>                    DBpath: /path/to/user/.palm/backup
> 		   Datebookdb: /path/to/user/.palm/backup/DatebookDB.pdb
> 		   TitraxNoteDB: /path/to/user/.palm/backup/TitraxNoteDB.pdb
> 		   TitraxDataDB: /path/to/user/.palm/backup/TitraxDataDB.pdb
>            }
>
> My intention is that the last three arguments would be optional if DBpath is
> set.  If none of the arguments are set, I'm thinking I can pull the path off
> of InputDB, which would be set to /path/to/usr/.palm/backup/TitraxNameDB.pdb
> (I think) given this config.

	This sounds reasonable. Personally, I would write the conduit to
use the arguments above as default values. That is, by default it will
assume that the Note database is "TitraxNoteDB.pdb", and is located in the
same directory as InputDB (that is, take InputDB and chop off everything
after the last "/").
	If the "TitraxNoteDB" argument is given, see if its value begins
with a slash. If yes, then use the value as the path to the database.
Otherwise, use it as a relative pathname under the default directory.

> Does this sound like a reasonable approach?  Are there better ways to handle
> palm apps that have/use multiple DBs?  Assuming this is a reasonable
> approach, my next question becomes, what's the best way to implement it?
>
> Looking at Palm::PDB, it seems to only be designed for dealing with one file
> at a time.

	I'm not sure what you mean about this. See below.

> Given this constraint, I'm thinking I should create three sub
> classes (one for each file) derived from Palm::raw.  This seems ugly, so if
> someone has a better idea, please speak up! ;)  It'd be nice just to have
> Palm::Titrax, not Palm::TitraxName, Palm::TitraxData, Palm::TitraxNote.

	Well, you could always go with Palm::Titrax::Name,
Palm::Titrax::Data, and Palm::Titrax::Note. This seems reasonably perlish.

	You said that Palm::PDB seems to be designed for dealing with only
one file at a time. Actually, each subclass of Palm::PDB is intended to
deal with only one _type_ of file. However, you can handle multiple files
of the same type:

	use Palm::Memo;

	$memo1 = new Palm::PDB;
	$memo1->Load("Memo1.pdb");

	$memo2 = new Palm::PDB;
	$memo2->Load("Memo2.pdb");

> If I take this approach, then I'd need a container class to hold four PDB
> objects; three Titrax DBs and one Datebook.  The current coldsync class only
> holds one.  Should I create a new class derived from coldsync to accommodate
> the extra PDBs or just code a conduit with three local PDB objects?

	Go with whatever you feel most comfortable with. I think both
approaches are defensible. I guess the main criteria should be the extent
to which you think you might reuse your code, and how much the extra
encapsulation might get you.
	If you're used to C++- or Java-style object-oriented coding, it
may come as a shock to learn that in Perl, you can just reach into another
class or object and use its methods and members (you're discouraged from
doing this because it isn't polite, is all).
	In particular, take a look at the ParseArgs and ReadHeaders
functions inside ColdSync.pm. They're just functions, not methods, so you
can, in principle, use

	use ColdSync;

	&ColdSync::ParseArgs(@ARGV);
	&ColdSync::ReadHeaders();

However, RTFS before you do this, to make sure they'll work for you.
They're not documented, which is the standard Perl way of telling people
not to use a certain function, but I don't remember whether this was
because I thought they'd break if used outside of the ColdSync module, or
simply because I hadn't cleaned them up to make this easy.

	In other words, there's nothing magical about the ColdSync module:
it just provides a convenient way to implement the most common type of
conduit, but the ColdSync<->conduit interaction is fairly simple. See the
"ColdSync Conduits" texinfo file for more details.
	So if it were me, I'd just raid ColdSync.pm for useful code and do
things by hand, rather than subclassing it or whatever.

	The other possible class, which might be more useful, would be one
that unites the four files being used.
	If you just load the four files, you'll have to keep track of
relationships like the one you mentioned above:

: Also, the TitraxNoteDB is cross indexed with it.  ie, the
: project name for record 5 in the noteDB is record 5 in the NameDB.

So if you delete NoteDB record #5, you'll also need to delete NameDB
record #5. Presumably you'll write some helper functions to do this. If
there's a lot of this sort of thing going on, you may want to write a
Titrax class that keeps track of everything (it need not be subclassed
from anything, since Titrax _has-a_ Titrax::Data, but not Titrax _is-a_
Titrax::Data).
	But I guess this is a bit of a tangent.

> Due to my limited Perl experience, I'm probably making this more
> difficult/ugly then it needs to be.  If there are better/easier ways to
> code this, please let me know.

	"more difficult/ugly" depends on what you're trying to do. You may
want to start out doing it by hand (looting^Wadapting code from
ColdSync.pm if it seems useful), and see what you actually need.

	Having said this, there's nothing that says you need to do this in
Perl. ColdSync communicates with conduits using nothing more than
command-line arguments, stdin/stdout, and a few environment variables.
	If you're more comfortable with Python, Ruby, C++, Lisp, or
whatever, and are willing to spend the time to write a module that'll make
it easier to write conduits in that language, then by all means write it
and send it in.

-- 
Andrew Arensburger                      Actually, these _do_ represent the
arensb@ooblick.com                      opinions of ooblick.com!
                        Generic Tagline V 6.01
-- 
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.