RE: One db, multiple conduits?

[Bharat Mediratta <Bharat@xxxxxxxxx>]

Alan Harder says:
> > Now getting down to the real question: can I sync with my address
book
> > conduit as outlined above *AND* with Alan Harder's upcoming address
book
> > conduit *WITHOUT* problems like changes not propagating correctly or
> > even propagating at all?  Is it even worth contemplating such a
conduit
> > or should I hack this functionality into Alan's conduit when he's
> > finished with it?
> 
> Martin,
> 
> As you probably know, the pilot maintains a "modified" flag for all
pilot
> records.  To make synchronizing faster, most conduits use the
> getNextModRecord() method to retrieve only changed pilot records and
avoid
> downloading the whole database.  At the end of the sync the modified
bits are
> cleared, since all the changes have presumably been copied over to the
desktop
> side.

What this means is that the first conduit could do a fast sync (looking
at only the modified record times) but the second one would probably 
have to do a slow sync (looking at every record).  If the first conduit
did not purge the modified bits and the database stored the modified
bits for whatever records were changed in the first conduit's sync, then
it's possible that the second conduit could do a fast sync.

The concept of a meta-conduit is pretty interesting, though.  It would
require a lot of work but it would make PilotManager into a much
more flexible tool.  It would probably make PilotManager the best sync
platform available for the Pilot.  By introducing a new layer we could
create a new class of "adaptors" that connect a desktop implementation
like CDE or rolo to the conduit.  Have at it!

-Bharat