Re: set_pilot_id and MAL conduit

[Eskil Heyn Olsen <deity dbc dk>]

On Wed, 1 Dec 1999, Vadim Strizhevsky wrote:

> Any particular reason why you didn't add to this to syncrhonize? Cases
> 10,5 and 8 ? Or am I missing a bigger picture here? I even think that
> should be inside add_to_pilot, NO?

They shouldn't be nessecary, as the local system should keep the ID number
in all cases. I cannot see a situation where the local system (even case
5, where the local record has been deleted) can match a remote record that
can be modified, without retaining the pilot ID number. And this ID number
should be set in the record generated by transmit.

And if that ID is different (or 0), the stored record will a new record,
not the old, thus duplication the record.

So in that case, adding the set_pilot_id to add_to_pilot will only slow
down the conduit.

I can add some paranoia checks, so returning a record with ID 0 (meaning
the pilot gets to assign an ID) causes a call to set_pilot_id, and if the
assigned differs from the input (which I am not sure whether can happen or
not) also call set_pilot_id.

But I grant you, that always calling set_pilot_id cannot foul anything up,
just slows down the conduit. (but not in a noticeable manner)

>  > The MAL conduit I slammed together sunday night is available at
>  > www.gnome.org/gnome-pilot/download/mal-conduit-SNAP.tar.gz. Since I almost
> Now _that_ is just soooooooooo COOL! Works great too. 

Cool until you enable the backup conduit. The changed db's get backed up,
that times way to much time. I really need to add a flag to backup
conduit, so it can be configured to not backup conduit managed db's (as
3Com prescribes), and/or create a capplet to manage the db's on the pilot
so one can enable the exclude flag.

/dev/eskil
---