[Kolab-devel] No x-uid please. (was: Re: [NEW KEP] KEP #17: Kolab XML Format 3.0)

[Christian Mollekopf]

On Tuesday 13 March 2012 16.52:28 Jeroen van Meeuwen wrote:
> On 2012-03-13 15:51, Christian Mollekopf wrote:
> > On 2012-03-13 14:48, Jeroen van Meeuwen (Kolab Systems) wrote:
> >> - A client not aware of the x-uid attribute, nor what it's value
> >> means, has *no* chance in either of the aforementioned cases to
> >> refer back
> >> to the contact object.
> > 
> > Yes, obviously. It also has not if it can't make use of an imap url.
> > With the imap url you're completely lost and have a disfunctional
> > distlist, while with mailto you have at least the distlist covered.
> 
> "If it can't make use of an IMAP URI" is quite the moot argument. It
> has the same face-value as saying "if it can't do $x it's not a Kolab
> client".
> 

It is not. Making it easy for clients to implement support for the format is a 
key point IMO. Requiring them to get a contact object and figuring out an email 
address is clearly complicating matters.

> An IMAP URI is a perfectly valid, standard URI, rather well described
> in an RFC, and provides the linking capability, in a more consistent
> fashion than would deriving from a standard format.
> 
> Clients incapable of using IMAP URIs can be made to become compatible
> with an IMAP URI value for the member element.
> 

Mostly possible, but i.e. in an offline scenario you can't.

> Clients incapable of using a Kolab specific x-uid however, can not as
> easily be made to become compatible with the x-uid attribute to a member
> element - because it is Kolab specific.
> 

Using imap in this property is also kolab specific. At least I don't know of 
any other client doing that. I understand your point that not using x-uid is 
more standard compliant, but I just think the standard is broken in this 
respect. Also I don't see the harm in extending it, as the normal usecase is 
still served without the x-uid.

A cleaner solution would be to extend xCard of course.

> Try and provide functionality within the standards available as defined
> and implemented by the community, which is perfectly possible, as I've
> illustrated.
> 

I've already pointed out some of the problems with your approach. What you're 
suggesting is not trivial.

> Even without any completely xCard RFC compliant RFC-defined IMAP URI or
> x-uid attribute run-in-circles-format-fork, resolving the element value
> back and forth is perfectly possible.
> 

Yes, using the UID as a urn uri. That still requires the client to get all 
those contact items, parse them and extract the correct email address to be 
able to send out the email to the distribution list.

> Inefficient, perhaps, when, as a client, you are operating directly
> against IMAP, without caching or IMAP abstraction layer.
> 
> Caching, as I've mentioned, can greatly enhance a client's capabilities
> to handle changes needed in multiple locations, as long as the routines
> inserting objects into a relational database are sufficiently aware of
> the fact the format allows for references. One can imagine an IMAP
> abstraction layer can perform a similar task
> 

How would such an IMAP cache look? Like a server you can talk to using IMAP?
Or did you have something like akonadi in mind?
In akonadi I'm not sure how to resolve the imap uri to an akonadi item.

I don't see the imap uri working. The UID as reference is IMO a valid way to 
go about it, but I think it unnecessarily complicates matters. The imap uri is 
a pure optimization from what I understand (applicable mainly for webclients), 
that could easily be helped with some UID to imap uri mapping I suppose.

Cheers,
Christian

> Kind regards,
> 
> Jeroen van Meeuwen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20120313/0b71e3e1/attachment.sig>