directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pierre-Arnaud Marcelot" ...@marcelot.net>
Subject Re: [Studio] [Shared] New low-level LDAP Protocol Connection Wrapper for Studio using the Shared classes?
Date Wed, 17 Sep 2008 08:26:38 GMT
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 <elecharny@gmail.com>wrote:

> Hi guys,
>
> comments inline
>
> Alex Karasulu wrote:
>
>> Hi,
>>
>> On Mon, Sep 8, 2008 at 8:37 AM, Pierre-Arnaud Marcelot <pa@marcelot.net
>> >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
>
>
>

Mime
View raw message