[Kroupware] Web interface frontend

[Andreas Jellinghaus]

Hi Bernhard,


> We publish documents and code as fast and properly as we can.
> E.g. the Kolab client code is in CVS. Server architecture document
> on the website.

so this is something i can understand. "We are sorry, but all we
currently have is the concept paper, and we still try to figure
out if things might some day work like we promise".

at least i take it as this. so i suggest: let me tell you, what
works and what not. what the detailed design issues are, to not
only get a barely working solution, but one that might be good.

lets discuss details, like what schema might be usefull.
or whether distribution lists should be implemented by one
object with maildrop  "usera,userb,userc" or
three such attributes with the values "usera" "userb" "userc".

for the reference: currently both works.

or lets discuss how to build a sane DN. the example in the concept paper
is quite ugly. unless you are working at denic, you are NOT 
dn: cn=administrator, c=DE (and "administrator" is a very ugly name).

rather i suggest using a suborganization o=people (or ou=?), so you can
also have o=clients and o=suppliers as additional addressbooks within
dc=company,dc=de.

i somewhere got the statement the server do everything exchange does.
currently i'm gathering facts about what will never work, unless
someone modifies outlook (e.g. write a mapi plugin like bynari did).

examples:
 - outlook does not show the list of all users in a ldap directory,
   but presents the list of all users when connected to exchange.
   with ldap you have to search for something. this is very different
   behaviour for many users. 
 - freebusy publishing and shared calendars. as soon as people use
   the bynari connector to replicate their calendar to an imap folder,
   and make a mistake by creating a new appointment on the imap
   calendar, the freebusy information published is incomplete: will
   not include this item.

lets look at appendix b.
"we give examples of messages ... and stored on the cyrus imap server."

the message in questition shows the format sent to invite someone
to a meeting, and is not the TNEF/MAPIPROP format used for storing
the message. please change the wording to make this clear.
you mgith use my example i posted earlier (i can resent it, if you
want).

or section 4.1.2 reads "Attributes of an LDAP Business Card" and
then "userpassword:". 

no business card contains a userpassword to my knowledge.
an object might be both: a contact/person/... and an account
(or an whatwasthenameoftheitemthatallowestohaveauserpassword),
but a contact per se has no userpassword.

what about discussing this stuff in irc or on the phone?
i asked martin a week or two before about that, no response so far.

> The server guys are busy putting the features together
> we need to have with the known Free Software components 
> and following our published concept. There is not much room
> to change many details of what we have to implement first.

mostly the concept paper provides no details about the server.
and when it does as in some example it needs improvement (like the
dn's), or its plain wrong (like the vcard message following a text about
tnef files).

and: if you want true features exchange has, then we need to discuss
users managing distribution lists, we need to discuss how to build
a server system that supports sites, and all this stuff. and that stuff
is not easy. i found exactly one paper on ldap mailservers with sites
so far (based on linux/open source). 

this isn't the first project creating a bigger/better/whatever
mailserver. most of them have some nice features, but are not very
general, or have some design issue.

like all these web/ldap tools seem to imply some ldap structure (like
dns created with uid=...,ou=people), but none actualy seems to document
this fact or tries to be open for other structures, generic, or at least
explains why it has some assumptions.

open source create tons of windowmanagers, cd players, mp3 players, etc.
evaluating software to give it hundrets and thousands of users as
default software, i found most stuff not appopriate. 

it would be sad, if this project would go the same way.
there are already way too many "eintagsfliegen" open source projects
(german word for the flies that only live one day).

there is no guarantee ot make an open source project vital or even
successfull, but my experience includes not only the stuff published
by esr, but also some points like:
 - common licence without trouble
 - active in-depth discussions of features and implementations on the
   mailing list
 - code review. people reading and commenting on patches. several people
   working on the same code (not only "their" sections of a common
   code).
 - actualy integrating code from several parties.

i have asked for places to drop my stuff. it's in no state where the
public eye could find it usefull, but it might helep discussions.
i'd like to put my code somewhere, so people can review it and comment
on it. and most important: i'd realy like to get some information
whether we can implement the rather complex features, or how we can
work around outlook or bynari bugs and stuff like that.

so, can we do this?

andreas