[sync] Fields in Turba vor vcard import/export. Appropriate sources.php

[Todd Pytel]

On Sat, 2006-08-05 at 16:33 +0200, Karsten Fourmont wrote:
> Right. This is as it is for historic reason. Turba is highly flexible 
> when it comes to fields. You can use it to manage cooking recipes if you 
> want. The default fields for address books are somewhat inconvenient 
> when it comes to vcalendar export/import. First name and last name is 
> one thing, having the whole address in one field is another.

Yikes, I hadn't even gotten far enough in testing to notice that. Yeah,
that would make things difficult.

> I use a different sources.php that does more closely match the VCARD 
> structure. See below. You need to create approriate fields in your sql 
> database of course.

*Very* cool. After modifying the database (which seemed to require some
fields not listed in sources.php?) everything works flawlessly. Turba's
ability to automagically adapt to different source configurations is
impressive.

> Changing the defaults would be a good thing. But due to the large user 
> base I'd like to have a final view on what fields we need before 
> proposing a new default set.

I would at least suggest that your sources.php (or something similar) be
included in sources.php as an alternate, commented entry in current CVS.
It's not at all obvious to a casual observer that Turba can use
different field structures without rewriting the code. Just make clear
that if someone uses the alternate structure then they are responsible
for adapting the sql script.

Also, I talked with Patrick Ohly (the syncevolution maintainer) about
mime-types. He pointed me back to the spec docs, which are quite
specific that 'text/vcard' means vcard 3.0 and 'text/x-vcard' means 2.1,
at least as far as SyncML is concerned. See, for example, page 41 of

http://www.openmobilealliance.org/tech/affiliates/syncml/syncml_represent_v11_20020215.pdf

So it's definitely a good thing to keep the alias in the turba API.

Neat stuff all around. Patrick asked me to write up a bit about
configuring syncevolution with Horde, which I'll do, and that should be
included in the docs for the next syncevolution release. So hopefully
other people will be able to get things working very quickly. Are there
other things that need fixing, implementing, or testing that I can help
out with? 

--Todd