[sync] Sync4j class name and evolution

[Karsten Fourmont]

Hi Todd,

the idea is that the for any SyncML compliant device, no special  
SyncML device instance should be necessary. A new device should work  
out of the box as long it's in line with the SyncML spec. The DevInf  
data is supposed to be sufficient to take care of all device specific  
issues.

However with the Funambol sync4j Outlook connector client there have  
been (among others) two issues:

1) It doesn't send DevInf information
2) It uses the nonstandard prorietary sif mime types to exchanges data.

That's the reason why the special SyncML_Device_sync4j is in place.

> Changing the deviceID to just "evolution-home-tppytel" leads to the
> device being treated as an unknown, generic SyncML device, in which case
> everything works just fine because it's not being translated to sif.

> While this is fine as a workaround, it obviously doesn't match the
> meaning of the code very well.
Well, it does match the meaning very well ;-) The sync4j device type  
is just a hack for the prorietary outlook connector behaviour. If the  
evolution implementation doesn't need this hack, all the better.

> substring. But SyncML_Device_sync4j assumes that the client is Outlook
Well, it doesn't assume it's outlook. It assumes that it's the Sync4j  
Outlook connector which requires the strange sif data...

Not using the SyncML_Device_sync4j for syncevolution is definitely the  
better way.

Cheers,
  Karsten

Quoting Todd Pytel <tppytel at sophrosune.org>:

> The current class naming scheme is somewhat misleading. Using a
> syncevolution deviceID of sync4j-evolution-home-tppytel (sensible
> enough) leads to a SyncML_Device_sync4j object because of the "sync4j"
> substring. But SyncML_Device_sync4j assumes that the client is Outlook
> and presumes to convert everything to sif format by overriding
> convertServer2Client. This confuses syncevolution, which expects (and
> requested in Rx-Pref) to receive 'text/calendar' when syncing
> calendars.
>
> (The only reason I didn't notice this with the address book sync is that
> convertServer2Client only checks for 'text/x-vcard' and not
> 'text/vcard'. So it sort of accidentally worked right.)
>
> Changing the deviceID to just "evolution-home-tppytel" leads to the
> device being treated as an unknown, generic SyncML device, in which case
> everything works just fine because it's not being translated to sif.
> While this is fine as a workaround, it obviously doesn't match the
> meaning of the code very well. Syncevolution is built on sync4j, so if
> there's going to be SyncML_Device_sync4j class, then it should be part
> of it. Perhaps SyncML_Device_sync4j should be renamed to
> SyncML_Device_outlook and the identification algorithm modified
> appropriately?
>
> --Todd
>
> --
> sync mailing list - Join the hunt: http://horde.org/bounties/#sync
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: sync-unsubscribe at lists.horde.org
>