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

Gunnar Wrobel wrobel at horde.org
Tue Oct 11 15:38:18 CEST 2011


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

> On Tuesday 11 October 2011 14.14:29 Gunnar Wrobel wrote:
>> Why call it "braindead"?
>
> Because it does not provide free/busy, web interface, mobile phone
> synchronization or anything else that makes up a groupware system and that
> people expect to have today.

But that is an unfair comparison :) I would compare Google IMAP with  
what we have with our Cyrus IMAP on the Kolab server. Of course I  
could install free/busy, a web interface and mobile phone  
synchronization for Google IMAP as a backend as well - assuming the  
Kolab format would support an annotation-less mode.

> It's pure storage with no logic, thus braindead.
>
>
>> 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.
>
> ...or anyone providing virtual servers.
>
> That's a lot like saying "I don't like to use email, because it makes people
> dependent upon providers of servers." That is naturally true, but then there
> is a huge market of providers out there, and people can even run their own.

Administrating a Kolab server yourself is slightly more complicated  
then getting an IMAP account with any of the big providers like  
Google, Yahoo or the German web.de, gmx.de etc.

>
> All these options also exist for Kolab, and we're working to build a bigger
> market for providers in this, as well.

I don't doubt that but it will take a significant amount of time until  
the gap between the number of available IMAP providers and the number  
of Kolab capable IMAP providers will be closed.

>
>
>> 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.
>
> But in this case maximizing choice will cripple the format, based on the
> assumption that "anyone providing virtual servers" plus "anyone providing
> Kolab services" together is not a sufficiently wide market to give people
> independence on what to do with their data.
>
> I don't think that assertion is true today.

Maybe this is a misunderstanding. I couldn't possibly teach the  
average computer user how to run a Kolab server in ten minutes.  
Getting an IMAP account with Google would be a different matter.

>
> The second assumption you're making is that people would prefer to  
> store their
> groupware data in a pure IMAP drop with zero groupware capabilities on the
> server, in particular no web interface or mobile phone connectivity.

Where did I make that assumption? Of course not. It is no problem to  
provide this functionality for any kind of IMAP server - assuming the  
Kolab format would support an annotation-less mode.

Cheers,

Gunnar

>
> My experience suggests this is true for less than 0.5% of today's groupware
> users, and those would be the ones who'd have no problem setting up their own
> Kolab server somewhere - so they are precisely *not* dependent upon that
> feature.
>
> So it's a feature for a group of users that do not need it and would instead
> prefer to take an alternative route to addressing the issue, but introduction
> of the feature would cripple the solution.
>
> To me that is not a compelling case.
>
> 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




More information about the format mailing list