Re: One db, multiple conduits?

[Casper Dik <casper@holland>]

>The conduit will read a file and the Pilot database into memory
>structures and sync them there using some simple algorithms -- for each
>pair of records; if categories are correct and surname and first name
>match, then update the older record with information from the newer
>record -- and then write the databases back.  I don't think there will
>be much reusable code.
>
>What I'm afraid of is that there will be problems with the time stamps.
>If I recall right, a database stores some information about each record;
>most notably a "dirty" flag.  When the first conduit is finished, this
>information will probably be reset, to the second conduit's chagrin.
>How do I avoid this?


What I'd suggest instead of writing multiple conduits is to make
some sort of meta conduits.

It's relatively easy to write a conduit that simply synchronizes a
Pilot database with a perl "Data::Dumper"; type of of database.

In fact, such a conduit would be pretty generic; you'd use pretty much
the same code for address book and date book and memo's probably too.

So instead of:

pilot <-> pilotmgr <-> SyncCM1
pilot <-> pilotmgr <-> SyncCM2

You'd get something like:

pilot <-> pilotmgr <->  SyncDBGeneric(Datebook) <-> CDE Calendar manager
				     	        <-> Whatever
			SyncDBGeneric(Addressbook) <-> rolo
						   <-> netscape format

Sort-of like recursive conduits as you'd be able to select different
styles of addressbooks using some sort of conduit manager:

	- import only (in the standard comma delimited format)
	- output only (same)
	- rolo (input/output)
	- any source (input and/or output)

Obviously, this would mean some sort of many pass algorithm.

When synchronizing, you'd need to do some pretty complex stuff:

	- get all updated entries from the external sources
	- get changes from pilot
	- resolve conflicts between sources
	- send new entries/changed entries to pilot
	- export entries to all external sources

There are numerous advantages to such a generic approach vs a
Sync per addrss book format:

	- you keep a generic perl-dump format database handy
	  (for easy offline browsing and export to/import from new formats)
	- with the perl database, it's much easier to keep tabs on the
	  exact changes made on the pilot
	- easier construction of new off-pilot formats


Casper

------------------------------------------------------------------------
***********************************************************
*             This is a public mailing list!              *
* Please do not publish Sun proprietary information here! *
*        -  -  -  -  -  -  -  -  -  -  -  -  -  -         *
*             http://www.moshpit.org/pilotmgr             *
***********************************************************