[Kroupware] Kroupware replacing Exchange
Bo Thorsen
kroupware@mail.kde.org
Wed, 5 Feb 2003 13:07:56 +0100
On Wednesday 05 February 2003 12:22, Ivaylo Toshev wrote:
> =D0=9D=D0=B0 =D1=81=D1=80, 2003-02-05 =D0=B2 12:00, Tassilo Erlewein =D0=
=B7=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:
> > The KDE client AFAIK does not yet support IMAP shared folders.
> > Support for shared folders is not part of the existing contract.
>
> Maybe i am wrong but native Kmail supports Shared(Public) Folders, so
> what is the problem KDE Kolab Client not to support them ?
> And if there will not be Shared Folder support, and there will not be
> support for Shared Calendars, Tasks etc. , then i cannot see the point
> !?!
You misunderstand us here. What we're saying is that you can access shared=
=20
folders like any other IMAP folders. But they won't look like the shared=20
folders in Outlook.
> I am now using Evolution, which has all of this things (PERSONAL Only
> Calendar,tasks, etc.) like client, but have not Server part which
> support them and cannot write contacts,calendars and tasks on IMAP
> server but just locally on hard-disk
> Now you Build Server which can do these things, but the Kolab Client
> will use IMAP to store (JUST PER USER PERSONAL ONLY) tasks, calendar
> and contacts on IMAP server, but cannot use such things on shared IMAP
> Folders.
True. This is what we have been saying all along. The client won't have=20
this capability in 1.0, and we know this is a thing that needs=20
improvement.
> So where is difference in using Evolution or Kolab ?
> Just that with Kolab your own Calendars, Tasks... are on IMAP server
> and not locally ?!
=46or some users this feature alone is valuable. There other differences to=
=20
Evolution - the most important one being the ability to work with a free=20
server.
I think Evolution is a fine client, and it's my hope that the developers=20
of it will adapt it to work with Kolab, so we can have more applications=20
to choose from.
> But with both of them the only way to "share" Calendars, Tasks and
> others is to "invite users" and to use SMTP for transport layer (as
> regular e-mails).
Of course, that's the point of both applications. But as I said, shared=20
folders is one of the next steps. And now we even have the foundation to=20
make it possible.
> I am using notebook and i don't care if my PERSONAL (because there is
> no SHARED no in Kolab, nor in Evo) calendar, tasks etc. are on my hard
> disk or on IMAP (i prefer hard-disk in that situation, because it is
> faster ).
I completely disagree with you on this. First of all, it's not faster. The=
=20
only thing involving the server is the server synchronization. All normal=20
work is done on the cache, which is located on your harddisk. Second, I=20
want my mail folders to be on a stable server, so I won't have to care=20
about client machine stability - this is also something companies value=20
highly. Third, the ability to use IMAP as the storage makes it incredibly=20
simple to prepare my laptop for going on trips - just sync the mails.
> Why every efforts in Open-Source World to build Groupware Solutions
> blow over with user expectations ? I know that this is hard to do and
> to be free ! But as was said here, most of the things exist in "raw"
> format as features and maybe it is not so easy to be cooked ;-)
No; we did not "blow over with user expectations"! That is something=20
readers of this list did. Whenever someone says Groupware Solution,=20
people start thinking of a myriad of features they all claim are=20
completely basic in any groupware app. From the beginning we laid out a=20
feature list, and anyone who bothered to read that list knew exactly what=20
we were going to do.
You seem to claim that shared folders is what a groupware solution is -=20
and I disagree. We're building a complete solution to solve the problems=20
we specified.
I too have a long list of things I want to have - shared folders now being=
=20
one of them. But I also have to put out a stable client, and I will *not*=20
sacrifice stability over features for 1.0. Even if it will be stable=20
around beta 7 :-) (I'm actually confident that we can get it stable by=20
beta 6.)
> Keep the good work.
We will :-)
Bo.
=2D-=20
Bo Thorsen | Praestevejen 4
Senior Software Engineer | 5290 Marslev
Klar=C3=A4lvdalens Datakonsult | Denmark