directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Boorshtein <mboorsht...@gmail.com>
Subject Re: [ApacheDS][SP] Stored Procedure Languages
Date Wed, 14 Dec 2005 01:52:49 GMT
On 12/13/05, Alex Karasulu <aok123@bellsouth.net> wrote:
> Ersin, Mark,
MarC :-)



> Extended operations (along with controls as well) have been designed to
> allow users to expand the LDAP protocol while still maintaining
> compatibility across v3 servers and clients.  Extended operations are
> similar to ioctls in device drivers.  When something did not fit into
> the motif of a character or block device driver then an ioctl was used
> to handle out of band operations.  For example when you need to eject a
> tape from a tape drive you use an ioctl because it does not map to the
> existing entry points for a character device.  So in the same light when
> we have operations to perform or expose which do not fit the LDAP access
> model we use controls or extended operations.
>

I'm not questioning why extended operations exist, I am asking how the
apacheds team envisions them being used.  ApacheDS thus var is unique
among the directory server world.  Its one of the few places where
people are energetic about directories and when combined with the
talent and imagination of those working on the codebase some very
interesting ideas have come about.  I suppose it boils down to are you
building an enterprise ready directory or an experimentation platform?

While there are infinite ways to use nearly any development tool, that
doesn't mean they weren't designed with specific uses in mind.  Nearly
every successful tool and service was built with specific uses in
mind.

Use casing is a very basic tenant of software engineering which is
often overlooked and so could lead to products that actually don't
have the flexability they need.  The "authenticator" api in apacheds
is a good example of this as it is one of the things that makes the
use of apacheds as a virtual directory as I've deployed and used in
the past  (no, I don't want to rehash the "what is a virtual
directory" discussion) very dificult.  A percieved flexability
actually limits the system.

An example where use casing was very helpfull for me was when I
designed and implemented the first version of the JDBC-LDAP bridge. 
When I first wrote it, I assumed Octet String would want to replace
JNDI with their own LDAP apis to add a level of flexability to their
products (I knew very little about LDAP when I wrote the first
version).  Because of this use-case, I was able to easily swap out
JNDI for JLDAP when I needed capabilities that didn't exist in JNDI. 
So even though JDBC-LDAP has "infinite uses", a bit of use casing went
a long way towords the flexability of the system.

> Stored procedures allow our users to do what they like within the
> server.  It's not so important to figure out what these use cases are
> (although I can list a few that I personally would like to use them
> for).  What's important is how we expose these procedures through the
> protocol while remaining compliant/compatible.  Extended operations are
> a natural way to expose such operations.
>

Again, I disagree with the assertion that use casing isn't important.

> Extended operations are generally published and specified within RFCs so
> they will have specific extended operation handlers.  Others will be
> user defined (via stored procedures) and not necessarily published.  For
> this case a single extended operation for calling stored procedures will
> enabling users to effectively create any number of private operations.
>

Just because something has an RFC doesn't mean it's used.  Remember
that the directory doesn't provide value, the applications which use
it do, and there are very few applications which make use of extended
operations.

> Now here's some of the use cases I am personally interested in:
>
>  o House keeping operations (this list is huge but for example
> rebuilding indices)
>  o Management operations (ok so is this one but again for example
> mounting a new partition on a namingContext)

OK, so far these are more "internal" uses....things that applications
wouldn't use.

>  o Managing complex referential integrity in concert with triggers.
> What ever we cannot do using schema structures like dITContentRules,
> dITStructureRules and nameForms can be managed using these two
> constructs: triggers and SPs.

In theory this is possible, in practice I've rarely seen directories
make use of referential integrity (or if it has, its a management
nightmare).  I understand the theoretical arguments here.

>  o To implement complex operations on a large amount of data.  Sometimes
> its best to not pull entries from the DIT just to massage them and then
> push them back in.  These bulk operations are ideal for stored procedures.
>
Not sure I understand this one.  Could you give an example?

> Many things can be done with SPs.  The sky is the limit or your
> imagination.  We'll see all sorts of use cases emerge.
>

So is use casing the chicken or the egg? :-)

Marc

Mime
View raw message