[sync] Questions about vcard versions and mime types

[Karsten Fourmont]

Hi Todd,
thanks for the detailed analysis.
I put text/vcard back into turbas api again. I think it was removed as 
text/vcard is not the official name of the mime type. But I'm not sure. 
And having it in there certainly does no harm.
Please give it a try (new turba/lib/api) and give some feedback if it's 
working. I'll then merge the patch into the stable branch.

Karsten

Todd Pytel wrote:
> OK, I've solved my recently posted problem about syncing Evolution and
> Horde - the CVS version of syncevolution works correctly provided that
> you work around some differences in the ways the two apps name their
> mime-types. I'd be happy to submit a patch, except that I really have no
> idea what the "right" way to handle this is. I'm not a programmer, I
> just play one on TV. So here's the deal...
> 
> Evolution works natively in vCard 3.0 format. To reflect this,
> syncevolution sends a preferred rx-type of 'text/vcard' (= 3.0) with a
> backup rx-type of 'text/x-vcard' (= 2.1). Horde gets confused by this
> because it uses 'text/x-vcard' to mean 3.0 and
> 'text/x-vcard;version=2.1' for 2.1. Thus, the current code reads the
> device info and sends 'text/vcard' to Turba's import/export API, which
> bombs out. It's simple enough to change the code in SyncML_Device to
> adjust for this, but I don't know which side of this exchange is
> "correct" in its mime-typing, if any. Is this naming specific to Sync4j
> (or syncevolution) or is it standardized? Is it appropriate to do the
> workarounds directly in SyncML_Device or should the functions be
> overridden in SyncML_Device_sync4j? Or is the problem really with
> syncevolution and the way it names things?
> 
> --Todd
>