Re: ContactDb implementation

[Matt Davey <mcdavey mrao cam ac uk>]

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
> 
> Well, I ran into some kind of a disappointment.  I just was trying to
> sync the birthday field, but I noticed evolution can't handle the
> birthday field well. It only stores 2 digits, which makes it
> impossible to store a birthday from eg 1950, as evolution will
> interpret it as 2050.  And as the birthday was actually the main
> reason I started trying to sync the contactsDb, I don't know if I will
> continue this project directly...
> There is already a bugreport:
> http://bugzilla.gnome.org/show_bug.cgi?id=386668

Mind boggling.

>From reading the bug (master seems to be #339813) it seems that
it is locale dependent, so presumably the backend data representation
is capable of storing the time correctly, but it is getting mangled
between the gui and the backend (?)

Anyway, 'twould be a shame if this scuppered your ContactsDb project :(
On that front, I think the right thing to do is to present a single
address/contact combined conduit to the user (as David D. suggested).
This may make the code a bit more involved, but it is worth it to avoid
a never ending stream of confused users!  I guess the way to do it is
to register the conduit for the legacy AddressDb (which is faked on
OS5, as I understand it).  Then, when the conduit runs it can check
whether ContactsDb is available and, if so, sync with that instead
of AddressDb.  Perhaps you can split out the 'convert from
pilot <--> evo record' function into two functions, one for Contacts
and one for Address.  The jpilot code might be worth looking at, too.


> 
> Tom
> 
> - ----- Original Message -----
> From: Tom Billiet
> Time: 27-01-07 12:33
> > Hi,
> >
> > I've been looking for an easy way to support birthday sync with
> > evolution, but it seems somewhat tricky.  You have to use the contactDb
> > instead of the addressDb, and so it requires a lot of changes to the
> > addressconduit, as the structure of both databases in pilot-link isn't
> > the same.
> > For now I just made a testing conduit more as a proof-of-concept and a
> > way for me to see what's possible and what needs to be done. I have this
> > modification of the addressconduit attached.
> > It's a rather heavy modification, and it's actually not usable at all
> > for the moment. It only syncs the name, title, company and all the
> > addresses (which is not possible in the old addressDb) as an experiment.
> > I actually don't know how it's the best way to implement this further,
> > and that's why I'm asking for your help :-)
> > My current vision is to implement it like this (and that's how I've
> > started, but it can easily be changed): Implement it as a separate
> > conduit and name it contact-conduits that lives next to
> > address-conduit.  This for the following reasons:
> > - It requires a massive amount of changes, and this way the
> > addressconduit is guaranteed to stay working.
> > - As palm os 3 and 4 do not have the condactDb, we still have to support
> > the addressDb, and implementing both in 1 conduit will make it rather
> > tricky to implement it clean and to maintain.
> > - The implementation of gnome-pilot requires the conduit to give the
> > database id upon initialization. This id is different for the contact
> > and address Db, so I *think* (I might be wrong) it is not possible to
> > make it in 1 conduit and let the user in the preferences select if he
> > wants to use contactDb or AddressDb
> >
> > Disadvantage: It's rather confusing for the user having 2 conduits which
> > appear to do the same thing.
> >
> > Let me know you opinions, and hopefully I can find enough time to
> > complete this project.
> >
> > I've my current work attached. please note this is for
> > testing/demonstration only, it's not usable as most of the fields are
> > still ignored.
> >
> > Tom