directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: Question regarding code partitioning in Shared
Date Wed, 10 Nov 2010 19:36:27 GMT
On 11/10/10 7:34 PM, wrote:
>> LDAP asn.1 is using BER encoding, when Kerberos is using DER. Not really
>> a big deal though, as we are encoding and decoding the PDU the same way.
> The difference seems to elude me more often that I grasp it.

There are very few differences betwwen DER and BER encoding, most of 
those differences are not relevant in Kerberos and LDAP.
>> FYI, we had a separate package shared-asn1 6 months earlier, and we
>> decided to merge it into shared, just because it's a PITA to deal with
>> many jars when building an application on top of shared (we have more
>> than one : the server of course, but also the installers, Studio, the
>> API, groovy-LDAP)
> I thought that was what shared-all was for.  Then there is only one jar to
> include.  Perhaps I misunderstand.
We wanted to merge most of the 14 shared sub-projects because most of 
them are not useful. When it comes to ASN.1 codec, the problem is that 
there is a deep link between the codec and the data structures.

However, regarding Kerberos, we are currently working in a separate 
submodule, and at some point, we may recreate a sub-project for ASN.1, 
so that one who want to work with the kerberos codec can avoid including 
the whole shared stack.

It's still a work in progress.

Also note that we want to merge the Ldap API project with shared (n 
fact, shared will become the new LDAP API).
>> It's convenient.
> It just seems inconsistent with the architectural philosophy.  Oh well...

Again, work in progress :)

There are some other factors here, like cross-modules dependencies, 
cyclic dependencies, etc.
>> I'm just wondering if it would not be better to use the full stack,
>> except that the Backend could be a SQL implementation. T
> The framework I'm using for testing has other functions built on the SQL
> DB
> so I don't have direct control of what the backend is, if that's what you
> mean
> by the "full stack".  I expect that framework with my RADIUS in it to
> persist.
> Due to my familiarity with it, and my lack of experience using LDAP, I was
> inclined to integrate it there first.
np, your call.
>> Anyway, sounds like a very good addition.
> I thought it seemed to make sense for ADS.

Indeed !--

Emmanuel L├ęcharny

View raw message