[SyncEvolution] SyncEvolution in Fremantle

[Patrick Ohly]

On Wed, 2009-12-30 at 08:14 +0100, Ove Kaaven wrote:
> Ove Kaaven skrev:
> >> This is already possible, but we aren't sure yet how to maintain the
> >> different profiles. Right now, src/syncclient_sample_config.xml contains
> >> a "contacts" field list (internal representation) and "vCard" profile
> >> that is used both for the SyncML peer and the local backends, with some
> >> tweaks to let some properties be handled differently on both sides
> >> ("EVOLUTION" rule).
> 
> I found a case I'm not sure about.
> 
> If you add a Jabber address to a contact, the vcard looks like:
> 
> X-JABBER;TYPE=jabber:address
> 
> but if you add a "Ovi by Nokia" address, the vcard looks like:
> 
> X-JABBER;TYPE=nokiachat:address
> 
> (If you add both, they not unexpectedly become separate entries, on
> separate lines.)

At the moment, X-JABBER is modeled as a "jabber contact" info field
without attributes that further classify it as "general
purpose" (TYPE=jabber) and "Nokia" (TYPE=nokiachat).

Is that distinction really important? In other words, what breaks if the
TYPE is lost? Other peers will most likely not know about the special
type and treat a "X-JABBER;TYPE=nokiachat" like any other X-JABBER
entry.

If the distinction is important, then perhaps peers should better be
sent a X-JABBER-NOKIA.

> Is there a good way to model that?

At the moment, the TYPE is already lost when parsing the contact into a
Synthesis field list. We could preserve it by adding a JABBER_TYPE
similar to the existing JABBER_SLOT (= X-EVOLUTION-UI-SLOT parameter).

The next problem is that most (probably all, except SyncEvolution
itself) SyncML servers will return a plain X-JABBER without the TYPE
when the contact gets updated on the server.

Suppose we have X-JABBER;TYPE=nokiachat:foo locally and get back a
X-JABBER:bar. This probably needs to replace "foo", but should the
"nokiachat" be added back? There's not enough information to decide
that. It's more obvious when we get back a X-JABBER:foo together with
some other modified properties; in this case the TYPE should be added
again.

I'm not sure whether the Synthesis engine handles all of these details.
What it does is preserve X-JABBER when the peer doesn't support it at
all, but I am not sure about parameters. Needs to be tested.

One way of solving this problem might be via a "merge script". This is a
built-in scripting language executed by the engine when it receives an
update for an item. The script has access to the old and new item data
as fields and thus can implement such advanced logic before writing back
a merged item. See 
libsynthesis/doc/SySync_config_reference.pdf.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.