phpgroupware-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Kroupware] Re: [Phpgroupware-developers] [Fwd: Re: [users-groupware


From: address@hidden
Subject: Re: [Kroupware] Re: [Phpgroupware-developers] [Fwd: Re: [users-groupware] Kroupware]
Date: Mon, 16 Sep 2002 10:36:56 +0200 (CEST)

Hi Jason,

On Mon, 16 Sep 2002, Jason Wies wrote:

thanks for making us aware of PHPGroupware.
Please be assured that we had a very close look at this solution before
designing the Kolab Server.

Please also have a look at our study at
http://www.erfrakon.de/whitepapers/kurzstudie-groupware.pdf
(unfortunatly currently on in German available)

In this studdy we discussed also the PHP Groupware approach.

The result basically boils down to a limited user experience due to the
use of html and more important to a limited scalability with regards to
the maximal number of concurrent users.

> missing, then, is the server solution to handle the logic of
> appointments and emails and todos and access control and the rest, to
> feed to the applications. Guess what? That server is phpGroupWare.

No this is incorrect. The logic does not have to reside on the server but
on the clients! This is very important with regards to scalability. If you
put the logic on the server than as the number of clients increase your
server becomes slower. In contrast if the logic is in the clients than the
number of avaiable cpu cycles increases automatically when you add
clients.

> already exist and work well. I think if we work together on this we can
> finally bridge the gap between the client side and server side and
> advance the Free Software community that much further.

Thank you very much for your offer but hounestly I must say that the
architectures do differ to much in order to share real code.

> > conclusion... that it would suck. So as far as I can see kroupware is
> > krapware

Lets finally see if this will be the opinion of the users (windows and
Linux users) in about 2 months.

> >  > and pieces thrown together. Two of my specialities are - apart from
> >  > anything else - mail: smtp, pop and imap, together with LDAP, and I just
> >  > couldn't believe the choice of specs that I was reading on the Kroupware
> >  > site.

> > I agree with this. I couldnt believe what they were trying to call a
> > replacement to Exchange/Outlook. I have spent two and half years
> > starting the phpGroupWare project and helping it develop into a serious
> > solution. Building a well integrated groupware solution is not an easy
> > task and the spec I have seen on the kroupware website fo nothing more
> > than to create server storage for PIM data. That does not create a
> > groupware solution. Their free/busy time solution is a train-wreck of a
> > solution which is going to get out of sync on a regular basis.

The quality of our free/busy time solution is exactly the very same like
with Outlook/Exchange. When only using KDE client and the Kolab server we
can be coherent at nearly any time.

> > This also does nothing to solve one of the most common requirements a
> > groupware solution must provide to executives. That is the ability to
> > give their secretary rights over their calendar to accept/decline
> > meeting request and to view the actual details of their calendar. Execs

We do have this functionality implemented via ACL's.
We call this delegation.

> > time, but no details of what their boss is actually scheduled to be doing.

This is a wrong claim.

> > The use of IMAP as the data store is a serious mistake. IMAP is designed
> > to only store personal email messages. If userA needs to give userB
> > access to any their data, and so much of this is controlled in the
> > client, then userA ends up having to give userB his password, and at
> > that point has no way to limit what userB can do with his data. userA
> > could not limit userB to read only access because IMAP servers dont
> > really support that.

Sorry but this is totally wrong. Please reread the corresponding RFCs
describing IMAPv4.1. You may pay special attention to shared folders and
ACLs.

> > As far as I can see kroupware is nothing more than server storage of PIM
> > data + a flaky system for a shared free/busy time listings. It is not
> > groupware as much as they want to call it such.

You are free to have an opinion!

Regards,
-- martin

Dipl.-Phys. Martin Konold

e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Germanenstra?e 15, 70563 Stuttgart, Germany
mobil: 0175 4148693
fax: 0175 13 4148693
email: address@hidden






reply via email to

[Prev in Thread] Current Thread [Next in Thread]