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