Introduction

At ApacheCon EU we intend to meet up at the hackathon to discuss various aspects of
Directory Projects. This page is here to list these topics of discussion and to
summarize them.

General Discussions

Directory Community

• Vision for TLP
• Project Status Soundoff
• New Project Ideas

Infrastructure Issues

• IRC Logger/Archive
• Site
• CI
• Daily Snapshots
• Live ADS at Apache
• Solaris Zone
• Personal Pages and Directory Blog

Need for specific non-coder roles

• Documentation/Books
• PR/Marketing Person - A Minister of Propaganda (MoP)
• Project Management
• Recruiting & Community Growth
• Visionaries in various aspects: we need people to see and devise a strategic roadmap
  so our PMs can help drive us there.
• Google SoC
• Outreach to Other Synergistic Projects
• Training/Conferences

LDAP Studio Discussions

Moving to Maven ?

Our build system is getting bigger and bigger. We constantly have "problems" with integrating the latest version of Apache DS such as shared-ldap for example.
This move would also allows us to lighten the size of our SVN repo since we would be able to remove the externals dependencies (but we may still need the eclipse dependencies).
Currently the main issue for this move is that Maven seems to be very good to build library jars but not Eclipse Plugins or Eclipse RCP apps (due to Eclipse plugins dependencies.)

ApacheDS Discussions

Knowledge Sharing on ApacheDS Internals

I would like to give a hands on tour of ApacheDS internals for those
that are interested in getting into the nitty gritty details of the
server and it's present architecture in the 1.5 branch. I think we
can begin with a simple introduction following my presentation on
ApacheDS embedding background then we can try to hack the server to
see if we can do some refactoring together collaboratively.

ApacheDS Core Refactoring

There are several ideas floating around regarding how to simplify and
improve the operation of ApacheDS especially in the core. I'll list
these ideas here. Some of them by the way we may attempt to hack on
during the hackathon after the knowledge sharing session.

Scoping Variables

Right now Emmanuel started refactoring the interceptor methods and
the partition methods to consolidate the arguments in each operation
into a OperationContext object. This object will store request scope
parameters as is apparent from the name.

Another objective is to expose a means to cache and access session
scope variables for a bound connection. This is a bit tricky since
operations can originate from two sources: via the protocol or through
the JNDI provider when used in embedded mode. MINA has a way to associate
session information with a bound stateful connection. One idea is to
write a ApacheDS specific interface without exposing MINA specifics and
create an implementation which wraps the MINA session object when the
operation comes from the protocol provider. A different LdapSession
implementation can be used for operations come in from embedded calls
on the JNDI provider without going though the protocol. I guess
effectively all operations originating from calls made on JNDI interfaces
can be treated as if they are part of the same session. These should
be discussed.

Clear Separation Between JNDI and Core

Presently the JNDI provider and the Core (starting at nexus proxy
going into interceptor chain and entering partitions) are tightly
coupled. Once can even say the JNDI provider is part of the core.

This is creating several issues for us. First there is a impedence
mismatch between the core data structures and the server lifecycle
and JNDI and it's lifecycle for context factories. Furthermore
this is coupling is making it very hard for even seasoned ApacheDS
developers from making changes since information of both JNDI and
the core is needed to correctly maintain this code.

The idea we have been bouncing around is to clearly separate the
server side JNDI provider from the core. This might require the
creation of a custom core API for both configuration of the core
and for runtime operations. Also the lifecycle for the core will
need to be clearly defined to suite it instead of how JNDI does it's
thing.

The JNDI provider would then wrap the core. It would either create
a DirectoryService instance or use one that is provided via a JNDI
parameter. This clear separation would also allow us to wrap the
core with other API's that might come about though the JCP in
addition to JNDI.

Caching Intermediate Values in Session and OperationContexts

Right now many interceptors re-load and re-compute entries and values
respectively to handle the same operation. Sometimes the same value
which is constant thoughout the LDAP session is re-computed with each
request. This costs us in performance. If we can cache these values
and entries in the respective scope then we can improve performance
drammatically.

Cleaning up Authenticator API

Some have expressed concern over the Authenticator API. It might
be worth while considering how we can refactor it to improve operation
and maintainability.

Moving Configuration Parameters into DIT under ou=system

This idea is very compelling because it allows the configuration of
ApacheDS remotely via LDAP itself. Furthermore because we can
respond to change events through the event subsystem this allows
us to dynamically reconfigure subsystems without a restart. Also
it removes a lot of verbose configuration from the server.xml file
which is not remotely searchable as it would be within the DIT.

Also another advantage of this would be to take advantage of
replication when managing a cluster. If a sophisticated replication
policy configuration can be realized we can make it so some
configuration attributes can be replicated across a cluster.
This way making a change to a replicated configuration parameter
on one master will take effect on all nodes in that cluster.

I'm very keen on the idea of using a combination of smart defaults
with configuration within the DIT to reduce or eliminate the
server.xml file.

Also we need to consider how configuration will be handled as
we investigate the use of JMX which is discussed more in the
next section.

New Feature Initiatives

Exposing Diagnostic Information via LDAP and JMX

I think we should expose some virtual and real entries within the
system partition to track diagnostic information if enabled about
the server, it's status, and certain metrics. We need to discuss
this and it's intersection with JMX. I guess the same information
can be exposed via LDAP and via JMX.

Also note that it would be nice to turn on facilities dynamically
for recording performance information about operations taking place
in the server for testing and profiling purposes. I think our
profiling tools are insufficient to diagnose issues and bottlenecks
so we're going to need some invasive techniques that can be
toggled on and off.

OSGi Effort

Here we should discuss the benefits of OSGi and how it will impact the
design. We also need to review the hurdles sited before about taking
on OSGi.

Also do we get some freebees from OSGi like JMX?

Jetty/Asyncweb with DSML service

Replication

(perhaps too large to discuss)

Transactions

(perhaps too large to discuss)

Finishing off Triggers, and SPs

Solid Security Model with SecurityManager

Snapshotting, Rollback and Replay Logs