Re: improving the Evolution addressbook conduit

[Matt Davey <mcdavey mrao cam ac uk>]

Hi Nathan,

Good to hear from you, I was hoping you'd bite!

On Wed, 2008-08-20 at 19:56 -0700, Nathan Owens wrote:
> Hey Matt,
> 
> Been a long time since I commented on anything here. I'm finally
> getting back to a point where I feel like I can contribute again (or
> at least look at things).
> 
> The biggest thing that I've noticed with the Evolution conduits is
> that memcmp() is used to compare a Pilot record to the Desktop (Evo)
> record.[...]

Are you looking at address_conduit.c line 1599?  Is so, then it looks
like a Pilot record is first created from the Desktop record, and it is
that derived Pilot record that is compared to the PDA's version.  So I
don't think the memcmp itself is a problem.

> More below...
> 
> --- On Wed, 8/20/08, Matt Davey <mcdavey mrao cam ac uk> wrote:
> 
> > From: Matt Davey <mcdavey mrao cam ac uk>
> > Subject: improving the Evolution addressbook conduit
> > To: gnome-pilot-list gnome org
> > Date: Wednesday, August 20, 2008, 8:41 AM
> > I'm beginning to take a look at the Evolution conduits,
> > and have started
> > with the addressbook conduit.
> > 
> > I'm aiming to start by fixing some data corruption bugs
> > that have
> > annoyed me for a while.  An early win is fixing the
> > 'other' field bug: 
> >    http://bugzilla.gnome.org/show_bug.cgi?id=547223
> 
> Glad to see someone responded on this. Thanks for fixing it.
> 
> > There are several other bugs that need fixing and lead to
> > data rot.
> > Once that is out of the way I'll look at adding support
> > for ContactsDB
> > and the 'new' fields such as birthdays and photos. 
> > Support for
> > ContactsDB will require some limited new API on the
> > gnome-pilot side.
> 
> I don't know how much gnome-pilot would have to implement. Shouldn't
> the conduit just open/register the ContactsDB database type when
> gnome-pilot loads the conduit? Maybe I'm missing something.
> 
> Also, I was thinking maybe the first cut at the Contacts conduit could
> be a standalone conduit. A refinement would be to make 1 conduit where
> the user chooses which PalmOS version is being used. If PalmOS 5 is
> being used, then the conduit uses the Contacts database. If PalmOS 4
> or lower is being used, then the AddressDB database is used. Of
> course, the conduit would default to AddressDB since devices are
> supposed to support it.

My thinking along these lines is that we should aim for a single
conduit, and it should open ContactsDB-PAdd in preference to AddressDB.
I reckon this could be done with an alternative conduit instantiation
method that lets you supply a preferred DB and a fallback DB.  If both
are present, it will sync the preferred DB.  The pre_sync method in the
conduit can check which one is open, set a flag, and sync accordingly.

It would be a bit of a hack, but to avoid going near the .gob internals
of gnome-pilot I was thinking that the conduit would have a 'registered'
DB that was set to 'AddressDB' and that only at sync time would we
attempt to open the 'preferred' ContactsDB-PAdd.  A more natural method
would be to allow a conduit to register for multiple databases, and let
it figure things out, but that's probably a lot riskier to develop.

It will complicate the code a bit to support both DBs in one conduit,
but the advantages for the user are obvious, and it should be easier to
maintain a single conduit.

Thoughts?  If we can agree the API I might implement that first and then
cut gp 2.0.17 to release the HAL fix at the same time.

> > This work will definitely go faster if I get help from
> > people willing to
> > build from source and test modified gnome-pilot and
> > evolution/evolution-data-server source.  I can help you get
> > up and
> > running with a build-from-source setup.  If you have
> > time/skills to help
> > with the development, too, so much the better.
> 
> 
> Let me know when there's something to test or if I can help you with
> any of the code. I have a Tungsten E sitting around doing nothing
> right now so I could put any test data on it I wanted. Also, I've been
> working on a mapping of ContactsDB fields to Evolution EBook fields.
> There's quite a few EBook fields that don't have a complement in the
> ContactsDB, but I think the syncing should be able to be resolved.
> Unfortunately, I don't have access to that spreadsheet right now. I'll
> post a link in the next few days to the list (probably Saturday or
> Sunday).

If you've looked at some of the new ContactsDB stuff already, great.  I
presume that most of the additions will be pretty straightforward, with
the exception of photos which should be fun.

I'm still reviewing the existing sync logic, as I it is broken in
several ways, particularly in the phone/email fields.  For example, if
you have a synced record and then you erase a phone number in Evolution,
it is not erased on the Palm (evo conduit won't write 'blank' fields).  

Worse than that, I can create cases where Evo re-orders the fields on
the palm and in the process can leave the palm record with fields
duplicated with a changed name!  It's a little hard to explain, but try
creating a record on the palm with 'work', 'work', 'home' 'email',
'pager' with the first 'work' blank.  sync, then modify a field on Evo
and sync again.  You should find 'work', 'home', 'email', 'pager',
'email', with the final 'email' field containing the value of the
'pager' entry.

It's not trivial developing good logic here, but I think as usual Evo is
trying to do too much 'magic' and missing plenty of edge cases.  The job
is much harder than jpilot, which follows the palm desktop layout, as
far as I understand it.  The problem is that Evo has many more available
fields than the palm, and the palm can have (for example) 5 work phone
numbers.  It would be great if you could review any revised logic I come
up with and test.

Matt Davey        Two cannibals eating a clown. One says to the other
mcdavey mrao cam ac uk 	"Does this taste funny to you?"