Getting rid of (most) annotations? (Is: Question: Individual annotations vs One large annotation)

[Georg C. F. Greve]

Hi Bernhard,

On Friday 30 September 2011 22.38:36 Bernhard Reiter wrote:
> > There are use cases where XML objects are clearly the better approach,
> > there are also cases where they are vastly inferior.
> 
> I yet have to encounter such a situation.

Alec and I have already mentioned some.

Ultimately every case where information is strongly associated to a single 
folder, and every case where potentially meta-information is changing over 
hundreds of thousands of objects, e.g. tagging the results of a search, would 
force hundreds of thousands of objects to be deleted, re-written and re-parsed 
by every client connected to that account, and some of these objects will be 
several megabytes large. This is a very heavy operation in comparison to 
noting a single annotation change.


> Let me split out this discussion, because I believe getting rid of (almost)
> all usage of annotations in the Kolab Concept is the future. 

Actually I think it would break the concept irrevocably to a point that it 
becomes unusable in large installations.


> Yes, I would not save the configuration for an email folder within this
> email folder. So it has to be saved in a configuration folder, probably in
> a must- have configuration default folder if there is no other or in a
> subfolder. But the Kolab Client knows it is there and where to find it.
> Email client would not touch that folders, so no risk of breakage.

Because a client does not know which object have references on this folder 
unless it has parsed every one of them, which otherwise may not be necessary, 
and because the client may not have the permissions to adjust the path of the 
configuration object in shared user scenarios, or may not even see it, your 
argument actually does not counter the point.


> >  * More complexity
> > 
> > Where a per folder setting can easily be stored in a shared/private
> > namespace, and conflict resolution between different settings is easy,
> > doing the same through XML is more complex.
> 
> There is a hiearchy defined in KEP9, so a setting specifically for one
> folder does not have a conflict. Conflict resolution for concurrent writes
> can be handled like all other conflict resolution: the next interactive
> client preferably asks the user or decides.

I know you're an avid fan of additional user interaction. Personally I think 
that for cases where clients *can* behave reasonably without such interaction, 
they should do so in the interest of usability. Making a conceptual decision 
that leads to deteriorated usability is not a good option, in my view.

But your point actually did not really respond to the point made.

The XML space does not know a concept similar to namespaces which annotations 
provide, and trying to emulate it becomes *very* complex.


> A subfolder or the default configuration folder would be easy to parse.
> Quite likely a client would do this close to startup on this account,
> because the prefered and recommended mode of operation is
> a fully cached client, [...]

I understand that your points are from the perspective of a particular fully 
cached client and the design decisions it made in its data handling backend 
which might require a change to efficiently deal with annotations.

But this is *not* the only client, and most users want a web client, as well 
as mobile phone connectivity, both of which are *not* fully cached clients and 
which would suffer from pushing this limitation of one client into the server 
through such a conceptual change.


> The main point is that in a setting where a user accesses multiple email
> servers at once from one client, some of them will not be Kolab Servers.

If that server is not a Kolab server, it does not need to support Kolab 
functionality, which is all we're discussing.


> The chance is very high to hit IMAP servers that do not support the
> annotations like Kolab Server does. Getting rid of annotations makes all
> these servers accessible as additional Kolab storage and would thus
> make Kolab much more attractive.

Naturally such servers would not have all the server-side functionality, such 
as free-busy, web client, mobile phone synchronization, resource handling, 
invitation parsing and so on and so forth. So the question becomes: Why would 
someone want to use such a server when a Kolab servers is just a click away?

This kind of server would be a brain-dead data dump, with no way to know 
folder types from one another, as that requires annotations in the Kolab 
concept. Getting rid of all annotations would in fact break the concept on a 
very fundamental level.

The need for doing this through such a mechanism was a strong enough 
requirement that a pre-final version of ANNOTATEMORE was implemented into 
Cyrus. So if the concept had known an efficient and robust way of doing this 
without annotations, I am sure it would have done so when there were no 
annotations available.

Meanwhile METADATA is an RFC and a standard functionality in all the servers 
we are interested in. It is the basis of various advanced functionalities, 
such as special-use and such, which are being pushed by big players on their 
server sides and currently find their way into the various clients.

In fact, special-use will likely be underpinning advanced use cases such as 
the new CalDav server in Cyrus, and be used to identify folder types, so to 
know what is a Calendar folder. Sounds familiar?

In other words: By moving away from annotations, we'd not only be breaking the 
Kolab concept, we'd also be moving away from the standardized approaches to 
dealing with this kind of data at a time when the standard is moving in our 
direction.

To do so for a very marginal fringe use case (you said this use case was the 
main argument) seems unwise.

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20111001/17c71e98/attachment.sig>