Re: Submission of Internet Draft - Complex DirectoryLookupusingJ

[Marlin Pohlman <marlin@coradon.com>]

I echo Thomas Salters statements, while a JVM is difficult to embed, the value of
its inclusion far surpasses the challenge of implementation.

JDAP/JNDI enabled byte code in the directory has ramifications which would surpass
the capability of ECMA. Tim Howes and Frank Chen may have a better insight, but I
would insist if ECMA is included that some provision for byte code exist. I think
we can envision a day (in the very near future) where Java is the preview of the
standards community. In the interim, I suggest making specifications for a base
common Java functionality (which includes JNDI/JDAP and a modular JVM ) and which
may abstract or minimize the threading issue

Marlin Pohlman

Chris Tomlinson wrote:

> Another concern viz Java is that while it is cross-platform there are
> significant issues with embedding a JVM in an LDAP server. Not all platforms
> support native threads equally and a multi-threaded LDAP server is going to
> have difficulties managing the dispatch from non-java to java uniformly across
> all platforms. While I am quite the java supporter, as far as I can see java
> doesn't currently represent a sufficiently platform neutral approach to a
> standard server-side scripting system.
>
> I would have to agree with Paul LEach here that ECMA script would probably be
> more likely to fit the bill of a neutral server-side scripting approach that
> could be embedded into LDAP servers.
>
> An arms length approach such as the various java servlet engines could be
> easily done but would run afoul of the observation that Thomas Salter made.
>
> As Thomas has pointed out the real problem is defining an filter language that
> specifies what needs to be done and otherwise leaves the server free to perform
> whatever magic it can to evaluate the filter in the most performance effective
> manner.
>
> It might also be reasonable to add the concept of 'stored procedures' in the
> LDAP directory that would be essentially canned searches or filters that could
> then be called upon from different applications in a consistent manner. This
> would be a (small) step to providing for 'business rules' in a directory that
> would provide some schema independence to applications.
>
> ciao,
> Christine Tomlinson
>
> On 08-Jan-99 Salter, Thomas A wrote:
> > The discussion so far has centered around what can or can't be done in Java
> > vs. extending the search filter syntax.  I'm not sure this gets to actual
> > problem.  If the goal is improving performance of arbitrarily complex
> > searches, the Java approach is only a partial solution.  The Java control
> > does eliminate protocol overhead, but does nothing to speed up the database
> > searches.  The Java code is still issuing standard Ldap searches.  To
> > achieve high performance on large databases, the Ldap server and database
> > engine need to be involved in optimizing the searches.  This could be
> > achieved through an extended search filter.