[Thread Prev][Thread Next][Thread Index]

Re: One db, multiple conduits?



Casper Dik writes:
>>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.


This is a very good idea.  These generic "metafiles" need only contain a
few extra fields in addition to the standard information included in
every Pilot database: a time stamp and a creator stamp.  Actually, the
"Data::Dumper"; data could and should be held in RAM during the hotsync
process but should be written to disk between sessions.

The code to synchronize generic databases with metafiles should be built
into PilotManager.  By default, PilotManager would just take backups of
the databases, but when a metaconduit registers with PilotMgr it would
automatically get a metafile allocated.  If several metaconduits want to
access the same database, they'd do it through the metafile.


>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


I favor this idea of having one centralised metafile which is accessed by
all the relevant conduits.

+ The metafile would be the central repository on the workstation, from
  which the Pilot database could be restored quickly in case of Pilot
  amnesia.

+ Since the metafile is stored between sessions, it can be updated
  (read: synced) at any point in time.

+ The conduit can use all of the available information to decide which
  records need updating, a process which might not always be so simple.

+ Each metaconduit needs to sync with the metafile twice for full
  synchronization, but the second session can be skipped for
  non-critical purposes.

The conflict resolver Casper mentioned is a good point; sometimes
conflicts can't be solved without human assistance, and these GUI
conflict resolvers could be built as modules and executed based on the
database type.  But this implies that PilotManager is run in the
foreground (and under X).  There are rumours of a command-line version
of PilotManager, which naturally won't be able to handle record viewers
in the same way as the GUI PilotManager can.  And if there ever is a
daemon version of PilotManager it must be able to work on it's own.


>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


The possibilities are indeed endless... or at least they seem endless,
which is often just the same. :-) More to the point; automated
Pilot-to-Pilot syncing is something people need and want.  The problem
is that this kind of syncing does not handle time-critical issues very
well.

But where do we start?  I suggest we make a new PilotManager conduit
defining a new "metaconduit" or "subconduit" interface.  When the
functionality is satisfactory, the conduit could be merged into
PilotManager.  How about it?

--Martin

Martin von Weissenberg     <http://www.hut.fi/~mweissen>
If you see a sailing boat with an ant-hill north of the mast, you know it
has been going in the same direction for a pretty long time.
------------------------------------------------------------------------
***********************************************************
*             This is a public mailing list!              *
* Please do not publish Sun proprietary information here! *
*        -  -  -  -  -  -  -  -  -  -  -  -  -  -         *
*             http://www.moshpit.org/pilotmgr             *
***********************************************************


SourceForge.net Logo