Alex Karasulu wrote:
Hi all,
On Jan 16, 2008 5:26 AM, Emmanuel Lecharny <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi Alex, PAM,
if we are to go away from JNDI, Option 2 is out of question.
Anyway, the
backend role is to store data, which has nothing in common with
Naming,
isn't it ?
Well if you mean the tables yes you're right it has little to do with
javax.naming except for one little thing that keeps pissing me off
which is the fact that normalization is needed by indices to function
properly. And normalizers generate NamingExceptions. If anyone has
any idea on how best to deal with this please let me know.
Well, indices should have been normalized *before* being stored, and
this is what we are working on with the new ServerEntry/Attribute/Value
stuff, so your problem will vanish soon ;) (well, not _that_ soon, but ...)
and I
see no reason to depend on NamingException when we have nothing to do
with LDAP.
We still have some residual dependence on LDAP at higher levels like
when we talk about Index or Partition because of the nature of their
interfaces. Partitions are still partial to the LDAP namespace or we
would be screwed. They still need to be tailored to the LDAP
namespace. There are in my mind 2 layers of abstractions and their
interfaces which I should probably clarify
Partition Abstraction Layer
--------------------------------
o layer between the server and the entry store/search engine
(eventually we might separate search from stores)
o interfaces highly dependent on the LDAP namespace
BTree Partition Layer
-------------------------
o layer between an abstract partition implementation with concrete
search engine which uses a concrete search engine based on a two
column db design backed by BTree (or similar primitive data structures)
o moderately dependent on the namespace
Note the BTree Partition Layer is where we have interfaces defined
like Table, and Index. These structures along with Cursors are to be
used by this default search engine to conduct search. We can then
swap out btree implementations between in memory, JE and JDBM easily
without messing with the search algorithm.
This is where things get tricky... But as soon as we can clearly define
the different layers without having some kind of overlap, then we will
be done. The pb with our current impl is that we are mixing the search
engine with the way data are stored. Your 'cursor' implementation will
help a lot solving this problem.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
