From kroupware Sun Sep 29 09:57:07 2002 From: Andreas Jellinghaus Date: Sun, 29 Sep 2002 09:57:07 +0000 To: kroupware Subject: Re: [Kroupware] Web interface frontend X-MARC-Message: https://marc.info/?l=kroupware&m=103329301818480 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 _______________________________________________ Kroupware mailing list Kroupware@mail.kde.org http://mail.kde.org/mailman/listinfo/kroupware