Hi guys,

On Wed, Nov 26, 2008 at 4:57 PM, Emmanuel Lecharny <elecharny@gmail.com> wrote:
Stefan Zoerner wrote:
Hi all,

I am obviously not an expert on this architecture stuff. But I assume, this is outdated.
No need to be an architect to see that ! Even me, I can tell how outdated the Javadoc is :/

The current javadoc of the org.apache.directory.server.core.partition.Partition interface tells us

"An interfaces that bridges between underlying JNDI entries and JNDI Context API."

But JNDI has been removed from the core. Right?
Right.

What would be a better short description?
An interface that bridge underlaying storage of entries and the server API.  (Alex will confirm of give a better definition, I think)

That sounds pretty good, not sure if I can do better. 

To me the Partition Interface and various helper interfaces (i.e. Cursor) represent a generalized API for the storage of LDAP entries. The term "partition" was used rather than "backend" because a partition represents a portion (a part hence partition) of the DIB (directory information base) for storing LDAP entries.



Other question on javadoc:
class AddOperationContext from org.apache.directory.server.core.interceptor.context states the following:

"A Add context used for Interceptors. It contains all the informations needed for the add operation, and used by all the interceptors."

This is still correct, but it is used in Partition as well. Suggestion:

"An Add context used for interceptors and partitions ... "

What do you think?
If it is ok, I'll fix these docs (many other occurrences in other OpContexts ...).
That's ok. OpContext are really used in a mean to limit the number of parameters we have to pass to each specific operation (Add, Delete, etc). It has another major advantage of being extensible, at no cost.

Ideally these OperationContexts should extend the interfaces we use in the frontend and we should just call them requests.  We should work towards this convergence but it may not be easy.

Alex