[SORRY --- REPOSTING WITH CORRECT ADDRESS FOR JAMES, IN CASE ANYONE WANTS TO
REPLY]
Alex,
My apologies for the delayed response. I've been very busy working on other
parts of James, but have gotten to a point where JNDI is at the top of my
list for a variety of reasons. So you've got my focus, and I'm ready to
start coding with ldapd immediately.
I'll try to reply to the several messages that went back and forth on the
subject of using ldapd with James.
Alex wrote:
> In terms of James, perhaps the best means to standardize access to data
> is through JNDI. Relational data can be stored within LDAP and
> non-relational content can be accessed via some WebDAV JNDI provider or
> the JNDI provider for the file system. The JNDI LDAP provider can be
> used to index into the non-relational content using referrals that can
> be resolved by a separate JNDI provider. The power of federation in JNDI
> can hide the backing store mechanism using a common API regardless of the
> nature of the data. Let me give you a simple example where a JNDI LDAP
> provider and JNDI based WebDAV provider are used in concert:
> LDAP contains the users, groups and other relational peices of data.
> Mail or news content can be stored on disk pointed to by an LDAP
> referral using a webdav (http really) url scheme. Even the file system
> provider can be used via a file://some/path referral. Using the server
> side provider in ldapd and the webdav provider James can manage both the
> relational data and the content.
Alex also wrote:
> JNDI is generic enough to allow both very different backing store
> types to be accessed in the same way. The relational info in the
> LDAP directory stores header into and users and groups etc so that
> it can be queried. The relational info then uses an ldap referral
> to point to the body or content held in the WebDAV server. LDAP
> referrals can use any URL schema.
Yes, the ability to combine hierarchical access and relational lookup could
be a huge win IF it is implemented efficiently. I have always been a big
fan of JNDI as a generic data access model.
The first area to look at will be user repositories. I'd originally thought
of using JNDI for mail stores, too, but backtracked to use JavaMail with
custom stores because it would help in implementing IMAP. However, I am
open to revisiting the subject after we get user repositories squared away.
Remember that performance and control over a standardized file format (in
some cases) are important desiderata.
Alex wrote:
> there is a server-side JNDI provider designed specifically to
> enable easy integration for in-process embedding (~60 complete).
Current status? We'll want to use JNDI as our interface.
I've done an anonymous checkout from SourceForge. My Sourceforge ID is
NoelJB if you want to give me CVS rights. You've commented on various
aspects of where ldapd is, and that there are various changes afoot. Can
you let me know the status of what is available TODAY to get started with
prototyping? If you want to contact me directly (off-list) we can also
exchange IM or IRC information, in case you've time to help me jumpstart on
my end.
>From my perspective, the best thing to do might be to start with a
standalone test driver to exercise a user repository model, and then move on
to integrating that into James. I am ready to start work on that now, and
would be happy for your collaboration. :-)
I will reiterate that I believe you should submit ldapd for the Apache
Incubator, and I would be willing to be one of your sponsors. As I recall,
some of the Avalon folks also expressed a willingness to co-sponsor your
submission to the Apache Incubator. This would fit in well with Avalon,
James, the new Apache J2EE project, and possibly factoring out JNDI from
Tomcat into a common area.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
