directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: state of the front-end
Date Wed, 07 Jul 2004 06:25:14 GMT
Hi Jason,

This is a good opportunity for a run down of where we are.

> Just wondering what the state of the front-end is. Currently I'm using
> Clayton Donnelly's code ( as a front-end to an object
> store and I want to switch as it uses snacc4j.

Currently we have paused development on the Eve code base diverting our
attention on Snickers which is a streaming, NIO based, implemenation of
the Sample Neufeld algorithm used in the SNACC and SNACC4J runtime
libraries.  The more difficult part, the decoding, of Snickers is
already complete and tests show it handling everything that SNACC4J can
do except Snickers sucks wire where SNACC4J breaths heavy.  The encoder
half is still in progress.  I actually started formulating an approach
this week.  It could take anywhere from 3-8 weeks of constant
development but I won't know exactly until I really dig deep.

The Eve frontend code currently sits within the trunk of the eve svn
project.  This code is all NIO based.  This is important to note since
it will, as you know, require JDK1.4 or higher.  Behind the scenes it
uses SNACC4J but as stated this will change when the encoder is
complete.  The SNACC4J => Snickers swap will be transparent to you the
user so its safe to use it now.  This frontend is perhaps ideal for your
needs because it's in a primitive state where the handlers for the
various requests (Add, Del, ModDN ...) have not yet been implemented -
they are stubs for the time being.  It might be nice to make the request
processing component containing these handlers configurable so folks
like yourself can swap in your own handlers to perform ops against
custom backing stores.

> Is it currently possible to use the front-end with a custom backend?

Sure. There are a couple of ways you can do this.  

1) write your own request handlers.  
2) write your own backend partition implementation which plugs into the
backend subsystem of Eve.  
3) write your own backend partition implementation for old LDAPd using
Snickers instead of SNACC4J

There are some important tradeoffs to be aware of with both approaches. 
In case #1 you don't get a slew of services that come packaged with the
backend subsystem.  These will eventually include things like DN
normalization, access controls, triggers, replication and so on as they
are made available.  The frontend in this respect is very primitive and
is designed to be so for many reasons.  These services will be lodged
within the backend subsystem so they are available if the backend
subsystem is embedded without a frontend.  If you are not concerned with
most of these services that's fine but one of them you'll need to handle
yourself: that's DN normalization.  DN normalization is the process
where you need to make sure any protocol allowed variance in a
distinguished name does alter your results.  The process of
normalization involves things like possibly truncating multiple spaces
into one (without altering the tokenization pattern of the name), or
handling things like character case variations in input.  That's pretty
much all you would need to do to get up and running with approach #1.  

In case #2 the biggest draw back is the fact that the backend subsystem
is no where near completion.  Portions of it are waiting in the sandbox
and in the trunk to be massaged and assembled.

Case #3 requires some background.  First off we have resusitated the old
LDAPd code and intend to swap out the SNACC4J stuff with the Snickers
codec.  We will make this available for play after exiting the
incubator.  Now a benefit to this approach is you get free of SNACC4J
eventually when we do without paying the price for DN normalization. 
All you need to do is implement a custom backend as it is defined in
this old code base.  Now the draw backs are its old, rickety, and will
soon die out when Eve is ready.  Also two varients of the code exist,
one runs on Phoenix and the other runs on Merlin.

NOTE: Eve unlike LDAPd is container agnostic with service
implementations as POJOs.  Container specific wrappers are used to adapt
the POJO services to a target framework.  At this point only wrappers
for Avalon Merlin exist.  Peter Royal at some point said he might look
into writing Loom wrappers.  Perhaps you would be interested in writing
Plexus wrappers.  The choice is yours.

> What's the size of the front-end in JAR format?

For case #1, which I recommend, you're going to need 4 directory project
jars + the snacc4j.jar (71k) not including commons dependencies:

ldap-common.jar            128Kb
ldap-snacc-provider.jar    133Kb
eve-frontend-api.jar        33Kb
eve-frontend-impl.jar       63Kb

When Snickers is complete you'll only need to swap out the following

snacc4j.jar                =>    snickers-runtime.jar        ??Kb 
ldap-snacc-provider.jar    =>    ldap-snickers-provider.jar  ??Kb

This is without the Merlin wrappers (eve-frontend-merlin) which is
another 34Kb if you choose to go with Merlin.  The Merlin wrappers have
commons, concurrent, avalon and excalibur dependencies.  Again if you
choose to go the plexus route you'll need to provide your own wrappers
and are welcome to contribute them back to the project.

Hope that helps,

View raw message