[Kroupware] Free/busy vs. Outlook(s)

[Helge Hess]

konold at erfrakon.de wrote:
> If I understand you correctly you intend to possibly support the Kolab
> Server as a message store for Clients like Outlook or Evolution.

Yes.

> My limited understandig according to
> http://developer.skyrix.com/02_skyrix/SxArchitecture.png is that the
> zidestore is a middleware in order to translate between proprietary data
> typically residing in a database and clients e.g presenting ical to these
> clients.
> 
> Please be aware of the fact that it is intentional design of the Kolab
> groupware to not use a database backend and not to use an application
> server.

As you have correctly noted it is middleware and therefore doesn't 
require the data to be kept in a relational database backend. Since we 
also have the required libraries for accessing IMAP4 storages it would 
be quite easy to access the Kolab backend.

BTW: while iCalendar clients like Mozilla Calendar or Apple iCal are 
also supported by ZideStore, Evolution and Outlook communicate using 
WebDAV with the server - no (well, little) iCal is involved in this process.

> I have the impression instead of
> 	Kolab - zidestore - Ximian Connector - Evolution
> 
> technically
> 			Kolab - Evolution
> is a much better approach.

Technically it is. Nobody is offering to work on that approach in the 
moment ;-)

> IMHO the work with Evolution is not mainly transport or data format (e.g.
> API) but GUI related. Evolution needs some extra work for full support of
> the the Groupware Features in the GUI which as it looks to me the
> zidestore is not trying to solve.

Interesting.

Exactly what Groupware Features do you consider missing in the Evolution 
user interface ? I don't know the current state of the Kolab client, but 
I'm not aware of additional groupware functionality provided through it.

> To me it looks like you proposal is like:
> 	Kolab - zidestore - zidelook - Outlook
> 
> I think that
> 	Kolab - "some connector" - Outlook
> 
> is faster, more scalable and easier to deploy. The later is the technical
> approach of both Bynari and Konsec.

We don't need to discuss that to death, but:
- Bynari does not seem to work in a stable way, which is the only
   reason why (in my understanding) Konsec came up ?
- the Konsec plugin is not ready yet ?
- neither Bynari nor Konsec provide Evolution support, so there is
   no current offering for going that route
- ZideStore is more scalable for reasons we had discussed before
   and disagreed on ;-)
- deployment is easier, since you have a single server component which
   talks with a wide variety of clients instead of several separate
   Kolab specific client modules (exception: Outlook)

Your technical points are mostly correct, but you are missing that there 
are no existing offerings for that.

You are mostly missing (well, I'm sure you know ;-) that ZideStore 
support offers access to a multitude of clients in a single step while 
your approach (Kolab - XXX) requires a separate development for any 
client to be supported. After all that's the whole idea of a middleware.

Anyway, it was just an offering, if there is no interest, we are not 
going to implement it.

regards,
   Helge Hess
-- 
SKYRIX Software AG - http://developer.skyrix.com/