Question: Individual annotations vs One large annotation (conceptual riddle for the interested)

[Gunnar Wrobel]

Quoting "Georg C. F. Greve" <greve at kolabsys.com>:

> On Tuesday 11 October 2011 13.21:31 Gunnar Wrobel wrote:
>> I'm not a fan of abolishing annotations completely either. But I would
>> like to be able to make them optional for some of the central
>> annotations (such as the "folder-type"). With the current Kolab format
>> specification users are unable to move their Kolab data to any IMAP
>> provider they choose.
>
> The big question here is: Why would they want to move that data to braindead
> storage?

Why call it "braindead"? Assuming you'd store the "folder-type"  
annotation via an XML object you'd be able to use the functionality  
defined in the current Kolab format to nearly 100%.

Granted: for some of the newer KEP stuff that wouldn't hold anymore.  
But that is still not the major part of the functionality defined by  
the Kolab format.

> What is the use case?

Allow users to easily switch providers. Right now you need your own  
Kolab server for that. Assuming there'd be Kolab hosters you'd still  
be bound to those providers.

Of course you would still get your data out in most cases - you'd  
export/import it as iCal, vCards and so on. But that is basically what  
you get if you store your groupware data on any of the other groupware  
solutions around. The Kolab format would however allow you to switch  
from one provider to another by the same means people employ nowadays  
if they switch mail providers.

The typical "data-lock-in" you get with SQL based solutions is  
something the Kolab format could avoid. And it is a liberty I'd like  
the users to have. Is that a "use-case"?

>
> Because right now there is no use case here that I can see, and making
> invasive changes for all clients and limiting the overall solution through
> addressing a non-existing use case seems pointless.
>
>
>> Even if the use of annotations/metadata will get
>> more common in the future I doubt that providers such as Google mail
>> will ever adopt them.
>
> So you don't think they'll implement the RFCs they have been driving?

I didn't know they actually drove it. If so, I'm probably wrong.

>
> But even so: If someone wanted to move their Kolab data to Google, why would
> they want to do so by abusing Google as braindead IMAP store instead of its
> calendar and address book functionality? The data is there and can  
> be mined in
> any case, but without the convenience for the user.

If you can use any Kolab client with the IMAP store to access the data  
I fail to see the problem with that. IMAP is not "braindead" even  
without annotations.

>
> If someone wants to use Google, I suspect they'll just use Google, and not
> "crippled Kolab stored in Google."

I just mentioned Google because it's one of the larger IMAP providers  
around. There are of course many other ones as well. The vast majority  
of them does not support METADATA.

>
>
>> I thought Jeroen disagreed with Bernhard on using KEP#9 for allowing
>> to store stuff we currently have in annotations in XML objects. But
>> that was probably not the main issue but rather the question of
>> abolishing annotations completely. The latter is something I also
>> don't want as I consider them useful in many situations.
>
> They are the best storage mechanism for some cases.
>
> In other cases XML is better.
>
> It's about choosing the right tool for the job, because between these two
> tools, Kolab can achieve its full potential.

Absolutely. I also don't want to cripple the Kolab format or limit  
it's abilities. I would just like to support enough flexibility to  
give the users a maximum of choice.

Cheers,

Gunnar

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

-- 
Core Developer
The Horde Project

e: wrobel at horde.org
t: +49 700 6245 0000
w: http://www.horde.org

pgp: 9703 43BE
tweets: http://twitter.com/pardus_de
blog: http://log.pardus.de