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

[Richard Bos]

Hello Martin,


Op donderdag 10 november 2005 09:45, schreef u:
> I added some comments.

That's really super :))  Thank you for your interactivity, that makes it nice 
to work with kolab!!!

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

- 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?

- 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?

- 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?


- 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


- 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?


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)?



I visited the linuxworldexpo today in the Netherlands and saw your name 
mentioned!   This was during the very initial startup stages of a notebook, 
that was connected to a beamer for a presentation ;)

During another presentation about groupware it was mentioned that evolution 
does not work with kolab.  As evolution can work with many (commercial) 
servers 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.....


-- 
Richard

-- 
Richard Bos
Without a home the journey is endless