Hi guys, Yesterday, there was an interesting discussion with an Eclipse commiter (tech lead for PDE) about an LDAP communication layer on IRC (#apache_directory_dev).
He wanted to know what kind of communication layer we are using in Studio. I told him we were using JNDI at the moment but we plan to move to a low-level LDAP Communication Layer. He explained that Eclipse has its own communications framework (ECF [1]) and that ECF may take advantage of that as a provider implementation. It could be interesting to have a look at that for our both communities. Here's the complete log of the conversation: ================================================================================ [19:00] zx: which LDAP library does Apache DS use to communicate with LDAP servers? [19:00] zx: I ask because some Eclipse.org projects are interested in the communication layer used by Apache DS, we would like to reuse this library if possible [19:01] pajbam: by Apache DS you mean Studio or Server ? [19:01] pajbam: Actually Apache DS is more the name of the server... [19:02] zx: oh, Studio [19:02] zx: I assume the library is available as a plug-in within Studio since Studio is based on Eclipse RCP [19:03] pajbam: Where using JNDI in Studio to communicate with LDAP servers [19:03] pajbam: s/where/we're [19:03] pajbam: that's the standard library bundled with the JVM [19:04] pajbam: If you're looking for the code, it's in the connection-core plugin (project) [19:04] pajbam: we're planning to write a new low-level LDAP Protocol communication Layer [19:04] zx: excellent, I can browse there. I was under the assumption there was something more magical at work here than just using standard JNDI [19:05] pajbam: because JNDI has a few drawbacks [19:05] pajbam: this new communication layer will be based on some classes developped for Apache DS (the server) [19:06] zx: very cool, we have a communications framework in Eclipse called ECF that may take advantage of that as a provider implementation. [19:06] pajbam: If you're instered, I started a thread about that on our Dev ML [19:06] pajbam: http://markmail.org/message/xr3lbkaozxx6tyvy [19:06] zx: Thanks for your help [19:07] zx: keep up the good work, you guys are one of the best Eclipse RCP apps I've seen out there [19:07] pajbam: "we" means you're from the Eclipse Foundation? [19:08] pajbam: hehe thanks... [19:08] zx: I'm an Eclipse committer (tech lead for PDE) [19:08] zx: and amongst other things at Eclipse [19:08] pajbam: cool [19:09] pajbam: It's great to see you looking at what we're doing [19:09] zx: you guys should reapply for the best open-source RCP app for EclipseCon 2008 when the time comes [19:09] zx: you were close last year [19:09] pajbam: yeah,but we can't unfortunately [19:09] pajbam: it's in the rules... [19:09] zx: we will see about that [19:10] pajbam: looool [19:10] zx: I thought you couldn't win more than once :P, we'll see [19:10] zx: we are doing planning for EclipseCon now and the topic will come up in the future [19:11] pajbam: Don't hesitate to come on our ML, I think we'd love to collaborate more together [19:11] pajbam: especially if Eclipse is interested in some kind of LDAP Communication Layer [19:11] elecharny: zx, is there a plan to integrate Studio in a future eclipse package ? [19:12] zx: pajbam: I will touch base with Scott Lewis from ECF ( http://www.eclipse.org/ecf/) , he would be interested in that topic as he is the ECF lead [19:12] zx: elecharny: we were interested in the LDAP communications piece of Studio in some projects, but it seems everyone just uses standard JNDI with the same weaknesses [19:13] elecharny: yeah [19:13] elecharny: I think we will switch to something more powerfull in the next few months, as pajbam said [19:13] elecharny: JNDI is so crappy ... [19:13] pajbam: zx: OK, feel free to do it [19:13] zx: elecharny: well, that would be up to you, I think if Apache wanted to have a package at Eclipse.org for some of the tools relevant to Apache than they can... or just DS in this case [19:14] elecharny: zx, this is something we have to think about ================================================================================ Regards, Pierre-Arnaud [1] - http://www.eclipse.org/ecf/ On Mon, Sep 8, 2008 at 4:51 PM, Emmanuel Lecharny <[EMAIL PROTECTED]>wrote: > Hi guys, > > comments inline > > Alex Karasulu wrote: > >> Hi, >> >> On Mon, Sep 8, 2008 at 8:37 AM, Pierre-Arnaud Marcelot <[EMAIL PROTECTED] >> >wrote: >> >> >> >>> Hi all, >>> >>> I'd like to share a few discussions I've had these days with Stefan S. >>> and >>> Emmanuel. >>> >>> >> We also have some discussion with Alex, and also Howard Chu during the > last LdapCon in Köln last year, about a new Ldap API. Not to mention the > convos we had with soem Sun peeps 2 years ago about a new JNDI-v2. > > It's cool to see that we are having this convo again ! > >> I was talking to Stefan on IM on friday and we were wondering how we could >>> improve the LDAP Browser and the Connection plugin. >>> Stefan would like to get rid of the use of JNDI in Studio because of the >>> problems we have with this API. >>> >>> >> +1 > >> He enumerated a number of benefits to using a client "LDAP protocol" >>> oriented connection wrapper instead of the JNDI one: >>> >>> - Direct access to the LDAP protocol >>> - Direct access to the result codes (we now must parse the >>> NamingException message) >>> - Access to the message ID >>> - Network settings (timeouts, etc.) >>> - Threading >>> - Referral handling (JNDI tries to be clever to manage referrals >>> internally, but we want to manage them manually) >>> - LdapDN handling is poor in JNDI >>> - You have to set weird environment variables to make it working >>> properly >>> - JNDI has no cancel operation, you must use ctx.close() to cancel an >>> operation >>> >>> >> plus poor Controls handling, poor Extended Operation handling, messy > semantic for operation (JNDI Bind != LDAP Bind)... > >> We were wondering if the "Codec" classes in Shared would allow us to do >>> such a thing. >>> >>> >> Not pristine, but this is certainly a part of it. You have to combine it > with the Entry API, a network layer, plus certainly clean these codec > classes ;) > >> In the afternoon, I talked about this with Emmanuel who told me that most >>> of the classes of Shared could be reused easily but also that we might >>> need >>> to add new ones (for SSL/SASL client authentication, or >>> controls/extensions >>> for example). >>> >>> >> We must also make it easy to plug extensions and controls. ATM, > encoding/decoding controls is, to say the least, a PITA. Sadly, I don't see > how this could be done easily, but we must at least ease the integration of > a new codec for a control or an extended operation. > >> >> >>> He advised me to ask on the ML, so we can discuss things further and see >>> what can be done with what we have today, and what we nee to work on to >>> build this low-level LDAP protocol connection wrapper. >>> >>> WDYT? >>> >>> >>> >> >> I think we're talking about writing a modern LDAP API similar in nature to >> the Netscape API to replace JNDI. JNDI could use this API if it wanted to >> as well but this is a less abstract, more specific API for LDAP. The more >> specific the API is the less surface area it will have. The better it is >> to >> comprehend and test. >> >> > yep. > >> I like the idea of doing this and leveraging the Entry API Emmanuel has >> written to do so. It will be nice to have it align with things we use in >> Shared to save us the head ache and overhead of converting from one object >> type to another for example. >> >> > Certainly ! And will help also to get more people around this portion of > the code. > >> This is value. If you guys decide to embark on it then I would like to >> help >> and get involved too. >> >> > me too. > >> We might have some issues with the codec but we can fix that as we go. >> >> > Yep. > > I would also add that there are a few things around there which could be > looked at : > > https://opends.dev.java.net/public/standards/draft-ietf-ldapext-ldap-java-api.txt > > and some discussion with the OpenLdap guys would be very interesting. > > Thanks for bringing this subject back on the table ! > >> Alex >> >> >> > > > -- > -- > cordialement, regards, > Emmanuel Lécharny > www.iktek.com > directory.apache.org > > >
