Getting rid of (most) annotations? (Is: Question: Individual annotations vs One large annotation)
Georg C. F. Greve
greve at kolabsys.com
Sat Oct 1 10:26:39 CEST 2011
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
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
To do so for a very marginal fringe use case (you said this use case was the
main argument) seems unwise.
Georg C. F. Greve
Chief Executive Officer
Kolab Systems AG
e: greve at kolabsys.com
t: +41 78 904 43 33
pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 308 bytes
Desc: This is a digitally signed message part.
More information about the format