I take this to a new topic, because I think it is worth to discuss it in an extra thread at least :)
>I was looking into adding features into the >addresbook. I like your suggestion of making >another controller for it.
Well I think thats for sure the way to go. Else too much would accumulate into the main controller.
>The features that I would like to add are:
>LDAP lookups for easy additions to the >addressbook
>Verification of addressbook entries according to >LDAP data
>Expand addressbook schema like adding homepage >url, phonenumber, etc. Basically make the schema >more robust. There is probably a DTD out there >for what I thinking about. I will take a look >around.
Well I am not too much into the LDAP stuff, but I spent quite a while figuring out what is out there in general.
Basically my findings pointed out that a good solution would be to to decouple the problem completly and create a real "contact database".
That can be done with an architecture similar to jwma and an interface so the two things can interact nicely.
I am not sure if LDAP is the right way to store
a persons personal contact database, anybody that can shed light on this is welcome. I will look out but I am tight at the moment with my time.
What I did at least is seeing about creating an
OO layer that will serve between any persistant form and the actual application. Its closely related to vCard, which seems to be right for Contacts anyway :) For fun I am seeing about import/export of 2.1 and 3.0.
Further features like "highlighting" contacts
is then a point to be seen about when realizing the actual interface.
>Another feature I was thinking about is >automatically getting a user's first and >lastname from LDAP when they log in the first >time. This would be optional, ofcourse, since >not all people have an LDAP server around.
Well I dont think it would be difficult to achieve this, you can even try it from within
the JSP, discovering those values, and just make it a welcome screen that greeting you with your name or whatever :) (maybe JAAS is a way to get that tokens?).
>What do you think?
You see above, I am thinking about it too, I would enjoy a discussion that gives us insight and shifts us in a position where we can take the right decision for the main stream.
What do you think? :)
Dieter
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I totally agree that the addressbook should be written as a contacts database. I didn't mean to use LDAP as the store eventhough it would be a legitamate place to store this kind of info. What I meant was look for a current DTD for contact information. vCard is one. Then we could either integrate this DTD into the current users preferences or keep it external to the preferences.
What I meant with the first time login stuff was that when a user first uses jwma and they login in for the first time, instead of them needing to fillout the firsttime form with their user info, it will be done for them by looking up the fields in LDAP. A simple little feature that I was planning to add today. Speaking about adding features...
Where should new features be added? I see that you have a new development version but you do not have a source ball available. I was going to check things out of CVS but I was not sure if you branched the current version and gave it another name or if getting the HEAD would be enough. I guess I could try. If there are any features that you have wanted to add but have not had time, I am more than willing to add them. I work at a large University (40,000+ staff,students, and faculty) and I am responsible for replacing the current WebMail implementation (based on horde/imp http://www.horde.org\). I really like jwma. It is a lot more stable and much more robust than anything could ever be that was written in PHP. Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, first of all about the CVS. There is just one main branch at the moment. I will ensure by this evening that I issued a commit for everything.
(Ensure means I think I did but I want to be sure :)
Then the contact database thing. Well I am lacking the experience to tell what exactly is the right place to store each users contact database. Most likely the best thing to do is seeing about castor handling the persistancy. It can map objects to an RDBMS, to an LDAP and to XML like I do now. Anyway I think we should discuss the ideas floating in our heads to a point where we can go and do. Else we end with a hack and the code as documentation :)
Regarding the first time thing, well, the problem is to stay platform independent, that's why I never attacked this although I thought of it (nothing more simple then fishing it from the /etc/passwd ;).
I think the way to go will be a configurable option selecting something that fits like a plugin and delivers the naming. My consideration when I added it was, that it is the place where you can catch people that use the "new" service for the first time. This is the ideal moment for the admin to catch a users attention. Once use is a habit, users have the tendency to ignore ;)
Yet this position can be discussed too.
Brings me back to your size. jwma is in development, and I am not sure if it is stable enough to be deployed in your case. I tried to do a good job on the code, and most parts of it are documented. I am confident that it does the job, but to be fair, I warn you, and I mention that there is another Java webmail solution available that claims to work for such sizes: http://www.sourceforge.net/projects/jwebmail
It seems as if there are cases that proof it works, which I don't have, because I only got contact with a few people that really seem to use jwma.
However, if you decide for jwma I'll be happy to help you get it going and I would also be happy to have people joining the developers corner ;)
Dieter
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think the idea to collect DTD's that are around is a good one. However, I have just encountered one thing that is actually also the standard, and that is vCard. Yet, when you say DTD I think of a document type definition for XML.
vCard is more a mime format, and they just seem to be working on a draft DTD for an XML representation, which is close to the 3.0 standard (although I never saw a standard conform card, because of the CRLF as linebreak ;)
What I have done so far is tried to build an OO representation of the info that is contained within such a card. Means I formulated a Contact, and additional objects necessary to make up a nice OO representation. What I could not exactly figure out was the property grouping feature. Neither the 2.1 nor the 3.0 standards seem to be explicit about _which_ properties within a card can be grouped, and that leaves a lot of possibilities at the application layer.
I'll be happy about any kind of suggestions or discussions regarding to this.
I should also try to figure out a way to put development material on the net, so possibly joining members can take a look at it.
However, I think that making this contact db/ms right (i.e. taking it serious etc.) does not make us end up with a full project :)
It brings us close to a PIM library..no?
Suggestions and discussions welcome....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well I have tried to learn something about LDAP and directories in general, and I think it will take me some time to get running.
I would really appreciate if somebody with knowledge on that side would like to join the discussion.
As far as I figured out the way to go will be vCards. It is probably a good idea to have a:
1. A mechanism to read/write the vCard Mime profile (Standard) (some code exists)
2. A mechanism to read/write to LDAP (LDIF I guess). (IETF Draft of vcard schema exists)
3. A mechanism to read and write the vCard DTD XML (Draft).
4. A mechanism to persist to a RDBMS
5. a persistency respectively i/o layer that uses one or more of the above named mechanisms, and glues to an
6. OO lib that actually models a contact database, a contact and further aggregated objects (code framework exists).
Given this and some glue code, it should be possible to put up a Contact database manager, being as flexible as possible with the backend and yet as powerful as possible regarding the features and properties.
Any comments are welcome :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We currently use LDAP quite extensively at our site for directory information and have it tied to a number of other things that make it incredibly valuable for quick lookups for statistics on a particular user.
LDAP is one of several storage methods mentioned below that can serve two functions:
1) Storage and lookup of user data (preferences)
2) A 'directory' or phone book of sorts for
organizational lookup. This is the real value
of currently, though many sites use other
means to acheive the same thing.
Many sites make use of an organizational phone book in addition to a personal address book. In my opinion, those are two separate things. An individual user's address book should be stored with their preferences. But it would also be nice to have the possibility of looking at outside directory information to do searches for people within your organization.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would vote strongly for a RDBMS vCard implementation. Beyond the basic address book problem, group and list management needs to be addressed. We particularly need organization wide groups, sub-groups, and personal groups. All need to support groups of groups. Ideally, the implementation should be database independent (benign SQL, no stored procedures, etc) so changing the driver class name and connection URL should be all that needs to be configured. Another lurking snake is calendaring and the iCalendar standard. This is probably a separate project, but should be able to use the vCard database and the proposed iCalendar tags for the vCard Spec (RFC 2426 and RFC 2739) to schedule meetings automatically. The good news is that both the address book and calendar applications fit the JWMA architecture nicely. Good job Dieter.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, one point of the discussion is, that this kind of information is most likely best stored in a directory and retrieved from there.
If you have such requirements (groups, subgroups
etc.) you will most likely have an existing IT infrastructure, or you should probably have one and you will want to reuse that infrastructure for everything possible (single point of administration etc.). Probably another issue is then the ownership of the data. Personal addressbooks or calendars, group addressbooks or calendars etc. This carries us by far over the actual aim of Jwma.
My questions are now following:
1. How can we come up with golden middleway set of requirements?
2. How can efforts be focussed? There are ongoing developments in that direction, as this discussion touches many fields (James, Jetspeed etc.)
3. Who is willing to jump on development? We are talking about a medium to large sized project :)
Reagrads,
Dieter
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2001-06-16
I think I vote for LDAP on this one...
Fast query and retrievement, centralized data source and lighter workload on the host seems good enough reason for me...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It seems to me the correct use of LDAP is to get the connectivity information for the address book data base. There are too many relationships going on in a sophisticated address book for LDAP to cope with. So LDAP should be used as a simple phone book to lookup and connect to the real thing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2002-02-28
Hi,
Castor has come out with their Data Binding Framework to support LDAP to JDO conversion. Now, I suppose, it would be easier to have a LDAP database to provide Persistance Storage for Address Book and User PReferences Setting. Has any work been undertaken in this regard? If yes, then what is the status of the same? If not, then any pointers as to where the changes would be required to provide LDAP Support?
N.Ramki
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I take this to a new topic, because I think it is worth to discuss it in an extra thread at least :)
>I was looking into adding features into the >addresbook. I like your suggestion of making >another controller for it.
Well I think thats for sure the way to go. Else too much would accumulate into the main controller.
>The features that I would like to add are:
>LDAP lookups for easy additions to the >addressbook
>Verification of addressbook entries according to >LDAP data
>Expand addressbook schema like adding homepage >url, phonenumber, etc. Basically make the schema >more robust. There is probably a DTD out there >for what I thinking about. I will take a look >around.
Well I am not too much into the LDAP stuff, but I spent quite a while figuring out what is out there in general.
Basically my findings pointed out that a good solution would be to to decouple the problem completly and create a real "contact database".
That can be done with an architecture similar to jwma and an interface so the two things can interact nicely.
I am not sure if LDAP is the right way to store
a persons personal contact database, anybody that can shed light on this is welcome. I will look out but I am tight at the moment with my time.
What I did at least is seeing about creating an
OO layer that will serve between any persistant form and the actual application. Its closely related to vCard, which seems to be right for Contacts anyway :) For fun I am seeing about import/export of 2.1 and 3.0.
Further features like "highlighting" contacts
is then a point to be seen about when realizing the actual interface.
>Another feature I was thinking about is >automatically getting a user's first and >lastname from LDAP when they log in the first >time. This would be optional, ofcourse, since >not all people have an LDAP server around.
Well I dont think it would be difficult to achieve this, you can even try it from within
the JSP, discovering those values, and just make it a welcome screen that greeting you with your name or whatever :) (maybe JAAS is a way to get that tokens?).
>What do you think?
You see above, I am thinking about it too, I would enjoy a discussion that gives us insight and shifts us in a position where we can take the right decision for the main stream.
What do you think? :)
Dieter
I totally agree that the addressbook should be written as a contacts database. I didn't mean to use LDAP as the store eventhough it would be a legitamate place to store this kind of info. What I meant was look for a current DTD for contact information. vCard is one. Then we could either integrate this DTD into the current users preferences or keep it external to the preferences.
What I meant with the first time login stuff was that when a user first uses jwma and they login in for the first time, instead of them needing to fillout the firsttime form with their user info, it will be done for them by looking up the fields in LDAP. A simple little feature that I was planning to add today. Speaking about adding features...
Where should new features be added? I see that you have a new development version but you do not have a source ball available. I was going to check things out of CVS but I was not sure if you branched the current version and gave it another name or if getting the HEAD would be enough. I guess I could try. If there are any features that you have wanted to add but have not had time, I am more than willing to add them. I work at a large University (40,000+ staff,students, and faculty) and I am responsible for replacing the current WebMail implementation (based on horde/imp http://www.horde.org\). I really like jwma. It is a lot more stable and much more robust than anything could ever be that was written in PHP. Thanks.
Ok, first of all about the CVS. There is just one main branch at the moment. I will ensure by this evening that I issued a commit for everything.
(Ensure means I think I did but I want to be sure :)
Then the contact database thing. Well I am lacking the experience to tell what exactly is the right place to store each users contact database. Most likely the best thing to do is seeing about castor handling the persistancy. It can map objects to an RDBMS, to an LDAP and to XML like I do now. Anyway I think we should discuss the ideas floating in our heads to a point where we can go and do. Else we end with a hack and the code as documentation :)
Regarding the first time thing, well, the problem is to stay platform independent, that's why I never attacked this although I thought of it (nothing more simple then fishing it from the /etc/passwd ;).
I think the way to go will be a configurable option selecting something that fits like a plugin and delivers the naming. My consideration when I added it was, that it is the place where you can catch people that use the "new" service for the first time. This is the ideal moment for the admin to catch a users attention. Once use is a habit, users have the tendency to ignore ;)
Yet this position can be discussed too.
Brings me back to your size. jwma is in development, and I am not sure if it is stable enough to be deployed in your case. I tried to do a good job on the code, and most parts of it are documented. I am confident that it does the job, but to be fair, I warn you, and I mention that there is another Java webmail solution available that claims to work for such sizes:
http://www.sourceforge.net/projects/jwebmail
It seems as if there are cases that proof it works, which I don't have, because I only got contact with a few people that really seem to use jwma.
However, if you decide for jwma I'll be happy to help you get it going and I would also be happy to have people joining the developers corner ;)
Dieter
I had horrible luck getting jwebmail working, and that's why I'm here ; - ) Your app seems to be a lot more well thought out and better documented.
I think the idea to collect DTD's that are around is a good one. However, I have just encountered one thing that is actually also the standard, and that is vCard. Yet, when you say DTD I think of a document type definition for XML.
vCard is more a mime format, and they just seem to be working on a draft DTD for an XML representation, which is close to the 3.0 standard (although I never saw a standard conform card, because of the CRLF as linebreak ;)
What I have done so far is tried to build an OO representation of the info that is contained within such a card. Means I formulated a Contact, and additional objects necessary to make up a nice OO representation. What I could not exactly figure out was the property grouping feature. Neither the 2.1 nor the 3.0 standards seem to be explicit about _which_ properties within a card can be grouped, and that leaves a lot of possibilities at the application layer.
I'll be happy about any kind of suggestions or discussions regarding to this.
I should also try to figure out a way to put development material on the net, so possibly joining members can take a look at it.
However, I think that making this contact db/ms right (i.e. taking it serious etc.) does not make us end up with a full project :)
It brings us close to a PIM library..no?
Suggestions and discussions welcome....
Well I have tried to learn something about LDAP and directories in general, and I think it will take me some time to get running.
I would really appreciate if somebody with knowledge on that side would like to join the discussion.
As far as I figured out the way to go will be vCards. It is probably a good idea to have a:
1. A mechanism to read/write the vCard Mime profile (Standard) (some code exists)
2. A mechanism to read/write to LDAP (LDIF I guess). (IETF Draft of vcard schema exists)
3. A mechanism to read and write the vCard DTD XML (Draft).
4. A mechanism to persist to a RDBMS
5. a persistency respectively i/o layer that uses one or more of the above named mechanisms, and glues to an
6. OO lib that actually models a contact database, a contact and further aggregated objects (code framework exists).
Given this and some glue code, it should be possible to put up a Contact database manager, being as flexible as possible with the backend and yet as powerful as possible regarding the features and properties.
Any comments are welcome :)
We currently use LDAP quite extensively at our site for directory information and have it tied to a number of other things that make it incredibly valuable for quick lookups for statistics on a particular user.
LDAP is one of several storage methods mentioned below that can serve two functions:
1) Storage and lookup of user data (preferences)
2) A 'directory' or phone book of sorts for
organizational lookup. This is the real value
of currently, though many sites use other
means to acheive the same thing.
Many sites make use of an organizational phone book in addition to a personal address book. In my opinion, those are two separate things. An individual user's address book should be stored with their preferences. But it would also be nice to have the possibility of looking at outside directory information to do searches for people within your organization.
I would vote strongly for a RDBMS vCard implementation. Beyond the basic address book problem, group and list management needs to be addressed. We particularly need organization wide groups, sub-groups, and personal groups. All need to support groups of groups. Ideally, the implementation should be database independent (benign SQL, no stored procedures, etc) so changing the driver class name and connection URL should be all that needs to be configured. Another lurking snake is calendaring and the iCalendar standard. This is probably a separate project, but should be able to use the vCard database and the proposed iCalendar tags for the vCard Spec (RFC 2426 and RFC 2739) to schedule meetings automatically. The good news is that both the address book and calendar applications fit the JWMA architecture nicely. Good job Dieter.
Well, one point of the discussion is, that this kind of information is most likely best stored in a directory and retrieved from there.
If you have such requirements (groups, subgroups
etc.) you will most likely have an existing IT infrastructure, or you should probably have one and you will want to reuse that infrastructure for everything possible (single point of administration etc.). Probably another issue is then the ownership of the data. Personal addressbooks or calendars, group addressbooks or calendars etc. This carries us by far over the actual aim of Jwma.
My questions are now following:
1. How can we come up with golden middleway set of requirements?
2. How can efforts be focussed? There are ongoing developments in that direction, as this discussion touches many fields (James, Jetspeed etc.)
3. Who is willing to jump on development? We are talking about a medium to large sized project :)
Reagrads,
Dieter
I think I vote for LDAP on this one...
Fast query and retrievement, centralized data source and lighter workload on the host seems good enough reason for me...
It seems to me the correct use of LDAP is to get the connectivity information for the address book data base. There are too many relationships going on in a sophisticated address book for LDAP to cope with. So LDAP should be used as a simple phone book to lookup and connect to the real thing.
Hi,
Castor has come out with their Data Binding Framework to support LDAP to JDO conversion. Now, I suppose, it would be easier to have a LDAP database to provide Persistance Storage for Address Book and User PReferences Setting. Has any work been undertaken in this regard? If yes, then what is the status of the same? If not, then any pointers as to where the changes would be required to provide LDAP Support?
N.Ramki