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

Tue Oct 11 14:32:05 CEST 2011

On 11.10.2011 13:14, Gunnar Wrobel wrote:
> 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%.
>

Which makes the storage, frankly, functionally "braindead" in relation 
to Kolab functionality.

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

Euh, actually, I have 3 servers I happily exchange Kolab Groupware XML 
data with, that are not Kolab servers. What you need is a server of your 
own, but not a Kolab server per-se. That is purely because Kolab does 
not specifically seek to implement and improve upstream but rather 
creates its own little circles to run around in. The Kolab Format is one 
example of that. The lack of development processes and critical review 
(both greatly improved only recently might I add) is another example.

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

Tell me, what is the standard methodology *people* employ to switch 
mail providers? And what is the method for groupware 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"?
>

This "data-lock-in" as you refer to it equally applies to the Kolab 
Format. It applies to any application specific data format, regardless 
of whether an open specification one can use in all Freedom exists for 
said format. This however is not the traditional definition of "data 
lock-in" - the traditional definition of data lock-in implies needing to 
speculate and/or reverse engineer a data format and/or specifications of 
said format that are not available, or not Free to use and/or needing to 
take a best educated guess at getting one's data out. The rest is 
toolchain, not "lock-in".

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

Actually, IMAP is pretty braindead.

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

The software they run actually does support METADATA - and quite the 
bunch more interesting stuff, too. Most of them providers actually use 
METADATA. That is not to say the client you connect to said provider is 
eligible to use METADATA, though. It's called suppressing capabilities.

Kind regards,

Jeroen van Meeuwen

-- 
Senior Engineer, Kolab Systems AG

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

pgp: 9342 BF08