[Kolab-devel] No x-uid please.

Tue Mar 13 21:51:13 CET 2012

On 2012-03-13 18:40, Christian Mollekopf wrote:
> 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.
>

Again, moot for being circular reasoning. "We make it easier for our 
clients to implement functionality supported by the format by extending 
the format."

>> 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.
>

Actually you can. It's called using relative URIs.

>> 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.

Yet you cannot dismiss the validity of standards-compliant element 
values simply by arguing no client has implemented the standard (to its 
full capacities).

Perhaps our Kolab clients are the first to make use of 
standards-compliant format exploits to provide additional functionality 
- the path is not mutually exclusive with other clients doing the exact 
same thing for as long as the format continues to conform to standards.

Using x-uid, all bets are off.

> 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.
>

I'm sorry but I fail to recognize which problems you have pointed out 
with my approach, that actually contained a valid argument.

> 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.
>

Actually just using a mailto: uri should suffice. It can be made easier 
for clients to find corresponding Contact objects by allowing the 
headers in the RFC822 mail message (which are indexed and quickly 
searchable) to contain some of the payload of the Contact object.

>> 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?

I'm not sure why you would want to talk IMAP to a relational database, 
but consider what you can do even if you just cached the objects. For 
objects, you need to store the original IMAP folder location and message 
data and metadata (UID, headers, payload), and bingo, you have in the 
database what you need to get to it and what you get from parsing an 
IMAP URI. For distribution lists, this may even have a(n additional) 
direct reference ID to the contacts table, though it needs to maintain 
the original IMAP URI for processing later. Similarly, vice-versa, a 
Contact might have one or more additional references to distribution 
lists the contact is a member of. Smart caching can make many problems 
disappear.

> 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.
>

Whether the IMAP URI is the grand idea to provide the desired 
functionality through or not doesn't really matter to me. Read the 
subject of this thread: no x-uid please.

Adding it has been a decision that's been made too quickly without 
seeking any consult nor awaiting the feedback from too many other people 
that have a vested interest in the well-being of the format.

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08