On 11/10/10 7:34 PM, [email protected] 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 !--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
