[Kolab-devel] No x-uid please.

[Christian Mollekopf]

On Tuesday 13 March 2012 20.51:13 Jeroen van Meeuwen wrote:
> 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."
> 

I fail to see how that is circular reasoning.

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

Right. I know you can if you implement a special way to make it happen.
It still isn't a clean solution IMO. 

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

I don't think I'm trying to do that.

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

My point is, using the members uri attribute as non mailto: uri is mutually 
exclusive with having a format which is compatible to current email solutions.

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

- It is more difficult to implement (yes, I'm listing that again, because I 
still think it's a valid point)

- Just because we can link a contact, we still don't know which email address 
is needed for the distribution list (the contact could have several). I don't 
know of any mechanism to mark one address as the one to be used for a specific 
distribution list. This pretty much makes this a blocker as far as I see. (so 
we need mailto)

- It's not yet clear to me how to make a solution with an imap uri work in an 
offline scenario. All the solutions that come to my mind or have been suggested 
(relative uri, extracting the UID) seem to me more like a hack, and far from a 
sustainable and/or interoperable. Maybe I'm wrong with this one.

- The IMAP uri is only valid within a specific environment, where a UID is 
globally valid. That is not a problem per se, but since we currently have no 
other properties which depend on the context, we could i.e. attach the very 
same XML to a document. So that is something to evaluate first.

- With the mailto: uri the distilist is a standalone object, with a link to a 
contact it is not anymore. Again, not a blocker, just something to consider.

- The Contact might be moved, breaking the imap link. Additional complexity we 
rather stay away from I think.

If all of those can be solved/dismissed we can see how to implement imap 
instead of mailto.

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

That  would be a doable option. I still fail to see though why we would have 
to remove a useful, completely optional, non redundant information that can 
safely be ignored by any client.

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

Fine. I really don't see why this one is the problem now, if we have other x-
properties in the format as well (in similar situations). If you are right, 
and the x-uid really is a problem, we would need to consequently fix that also 
for:
http://wiki.kolab.org/User:Mollekopf/Drafts/KEP:17#Attendee
http://wiki.kolab.org/User:Mollekopf/Drafts/KEP:17#Contact
http://wiki.kolab.org/User:Mollekopf/Drafts/KEP:17#Related

While I only played with the thought of adding an x-uid also to Related, for 
the very same reason that it is in Member:
Make the basic implementation trivial (plaintext name), allow for more by 
giving the possibility to link a contact, without breaking the trivial case.

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

Yes, the decision was made quickly. It was however done in the public, and is 
not set in stone, giving everyone the chance to object, just as you did.

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/20120314/1cd17a36/attachment.sig>