[Kolab-devel] Is there still a reason for the resource-handlers module

[Bernhard Reiter]

Hi all,
actually I lost track of who wrote what in this email,
because I did not understand the quoting.
Nevertheless I just give my opinion on the topics.

Am Sonntag, 13. November 2005 23:14 schrieb Richard Bos:
> Martin,
>
> Op donderdag 10 november 2005 09:45, schreef u:
> > I added some comments.

> You can't do anything about the openpkg things, let's forget about it ;)

An OpenPKG thing should be brought up with the OpenPKG people.
Unfortunately they still have not answered my request about their
vision how to support enterprise distributions.

> - Renaming of the phplibdir and webserverdir from 'admin' to 'kolab'.
> MK: This should be easily doable as it does not affect the clients.
>
> RB: I think we can do this in the Build system (too).  We can just make a
> variable for it, e,g. @BLAH@ and in case of (distribution) kolab it will be
> defined as 'admin' (till 3.x) when it can be switch to 'kolab'.  In the
> meantime it can be defined on suse as 'kolab' from the beginning ;)
>
> Should this be a tracker?  But how to define it is one that must be done
> for version 3.x?

You can put it in the tracker as wish and create a topic "kolab3".
Please also put in the reasons for this change, as I am still unsure about it.
/admin/ does not seem to hurt as most real enterprise Kolab Servers should 
have their own DNS a record.

> - Perhaps the usage of current horde (components) and not the ones from cvs
> MK: Actually we should only maintain patches in our CVS not a copy.
> Keeping a copy is wrong by design (forking)
>
> RB: somebody should just do it.
>
> Should this be a tracker?  On going or for 3.x?

You can make this a wish in the tracker, too.
There is no need to wait for the next generation of the Kolab Server to do 
this, but also I do not think it is majorly important either.
It is one step to get close to mainline Horde.

> - No (email folders) under post in, but just straight under the server
> MK: This is easily implemented by the server (alt hierarchy operator),
> but needs support by the clients. I support this move as an option.
>
> No changes at the server at all (configuration option in kolab-webadmin
> maybe)?
> Tacker?  3.x?  Or should it be reported to bugs.kde.org?

As far as I understand, this does not really need to be changed at all.

> - Middle name support, see issue 606
> https://intevation.de/roundup/kolab/issue606
>
> RB: this one is very important, because it prevents people to administrate
> names correctly.  And people _HATE_ incorrect names, especially when the
> system prevents people to administrate their name correctly.
>
> Currently a person is called: "Piet van" iso of Piet or "van Oosten" iso of
> Oosten .  The problem now is that the sort output is not correct as well.
> The person is listed under "v" iso "O"!!
>
> Their might be a schema change needed to have this resolved, hence I put it
> for V3.x

Can you document in the issue how standard LDAP schemes and clients
are solving this problem?

> - The possibility to configure cachedimap and regular imap per email
> folder, or seperate for the kolab groupware folders (always cached imap)
> and the email folders (cached or regular imap).
> MK: This is pure client feature though not easy to implement
>
> RB: No server change needed?  That's nice.  Something for tracker or
> bugs.kde.org?

A wish at Bugs at KDE, I think it already might be in there.
And you can make a wish in our tracker to refer to the KDE issue number.
Can you also restate the intended use cases for the feature?
As far as I can tell it would be on the case when you do not want to fill
up the local cache, because you have many emails in there.
For appointments or contacts that does not really help as the client would 
need to build a complete cache in memory anyway before you could use
the information right away.
In this case you could already only subscribe to the contact and email
folders and use online imap for the emails.
So to me: No real use case left.

> The possibility that email folder settings just like: 'order by group' are
> stored on the imap server.
> MK: Yes, we need yet another imap annotation for that.
>
> RB: https://intevation.de/roundup/kolab/issue953
>
> Does the addition of another imap annotation break current funcitonality or
> can it just be implemented (if time permits etc)?

It could just be implemented.
I am still unsure how many of the clients configuration should actually be 
saved in the imap annotations.

> During another presentation about groupware it was mentioned that evolution
> does not work with kolab.  As evolution can work with many (commercial)
> servers 

*cough* *cough* 
The Kolab Server is also "commercial",
it was developed for money, by professionals and you can buy commercial 
support for it.

> it was said to be a advantage for egroupware, because [long story]: 
>
> evolution: egroupware
> ms outlook: kolab, egroupware
> kontact: kolab. egroupware
>
> Now in case of migrating from exchange to OSS and starting on the desktop,
> one can only start with evolution (as kontact does not connect to
> commercial servers) and than to egroupware.....

Nah, I do not really understand that reasoning.
As far as I know the Evolution connector to Exchange requires at least 
Exchange 2000, and most people still have Exchange 5.5.
If someone wanted to have a migration tool for Exchange 2000,
they could contract us from the Kolab-Konsortium, as I estimate
that going the same route as the evolution connector it is easier to write
a one time converter for the migration.
Interesting enough evolution should understand iCalendar invitations.

Bernhard