directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: [Fwd: [ldapext] draft-ietf-ldapext-ldap-java-api-19.txt]
Date Fri, 11 Jun 2004 03:29:01 GMT
> Sure, I'd be interested at looking at other bits of the server to get a 
> better understanding of how things work. Fact is I know almost nothing 
> about LDAP.
> I'm not sure where to start though. What do you suggest?

Great but I always get scared when people ask me these questions. 
There's just so much to deal with and I find it hard to find a good
starting point.  Perhaps the best way to start is to fire up the server
and start playing.  At this point in time she just sits there telling
you she's busy no matter what you ask her to do.  Sounds kinda like a
girlfriend I had years ago :-).  

Perhaps you can begin looking at the plumbing by attaching to the
server's process and stepping through it.  At this point in time there
is only the front end plumbing setup.  There is a newly built back end
that was stowed away but its almost ready to go within the sandbox - it
needs to be dusted off and connected to the front end.  

For the time being though I would like to polish the code in the
server's front end by having it front another directory.  Perhaps you
could play around with this.  What the heck am I talking about?

Well the designs I have in my head have the front end and back end 
subsystems looking like a ball and socket.   The front end is the socket
and it takes the back end.  The joint is tied together using JNDI. 
Basically the front end should act like an LDAP server to JNDI LDAP
client call translator.  The back end subsystem is actually a JNDI LDAP
provider but it does not talk on the wire - just operates on back ends. 
So the coupling API between the front and the back is JNDI.

client JNDI calls --wire--> 
	eve server -calls- JNDI --wire--> 
		another LDAP server

What I would like to do is start testing the front end by having it use
the SUN LDAP provider to connect to another LDAP server.   Yeah that's a
crazy idea but this will come in handy down the line.  Basically we can
use this capability to merge entries across servers and translate
Directory trees making them appear totally different.  In the world of
directories I think this is referred to as a virtual directory but don't
quote me on that.  This also prepares the front end to have the back end
subsystem snap right into it (there is more to it though).  Furthermore
this also allows us to check and see that eve is actually working right
when run against servers like OpenLDAP and iPlanet.  There are of course
other ways we can verify correct operation but this black box tests the
front end in isolation from the back end subsystem.

Back to how you can nudge your way into this.  Basically if you take a
simple operation like Bind and see if you can implement it end to end by
having the front end receive a Bind request, process it by binding to
another LDAP server using the SUN JNDI provider, and return a response
to the client after receiving one from the server.  Then what we can do
is test the bits to make sure everything the client gets adds up with
what Eve gets back from the server.  You can do this with all requests
to start to understand them.  You might want to have a look at RFC 2251
while doing this as well as other associated LDAP RFCs.  So while doing
this to learn and get involved you'll also be doing valuable things to
get us on our way.

Does this help?

Alex




Mime
View raw message