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

Gunnar Wrobel wrobel at horde.org
Tue Oct 11 15:44:12 CEST 2011


Quoting "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com>:

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

Outlook PST. I'm guessing though.

> And what is the method for groupware providers?

Again guessing: In many cases this will be done by administrators in  
the background. If users switch on their own it will be a combination  
of iCal, vCard, PST and/or imapsync.

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

Thanks for clarifying the terminology. I agree then: it is the tool  
chain. Most people can work with a standard IMAP client which makes it  
possible to move between providers.

Cheers,

Gunnar

>
>>> 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
>
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format

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




More information about the format mailing list