------------ Forwarded Message ------------ Date: Saturday, December 16, 2006 7:38 PM +0200 From: Ersin Er <[EMAIL PROTECTED]>
On 12/16/06, Giovanni Baruzzi <[EMAIL PROTECTED]> wrote:
----------- Apache Developer writes in response -------------------------- LDAP Triggers have been modelled and implemented with X.500 Administrative Model based semantics in ApacheDS. As the current effort is on Schema Subsystem Redesign and Multi Master Replication, Triggers and Stored Procedures will get matured and reducted as RFCs in about 12 months. You may have a look at the following presentation(s) given at the last ApacheCon US: http://people.apache.org/~ersiner/apachecon-us06/
The use of the X.500 Administrative Model is admirable. We've had this on the ToDo list for OpenLDAP for a while, but generally the level of need never hit the critical point to motivate any of us to implement it. Since OpenLDAP subdatabases are administrative control points already, there's little gain in functionality for us at this point.
I'm somewhat skeptical about the Trigger spec, but that's natural since we already have our own overlay interface as well as Netscape SLAPI plugin support. And since we can load modules dynamically, the trigger design doesn't offer any gain for us either.
I'm extremely skeptical about the Stored Procedures; these aren't the sort of thing that regular users need to do. For a real-world directory being manipulated by many users, you're going to limit access so that only administrators can create them, otherwise you're going to see your directory server slow to a crawl the first time someone writes a deeply recursive procedure "by accident"... Also in general you're going to limit them to things that have been well-written and well-tested, for the same reasons. As such, for us the standard plugin model is already adequate for this purpose.
One thing I've noticed about ApacheDS that I like is the forward-looking support for new Attribute Syntaxes. I've been developing something like that for OpenLDAP for quite a while, though my approach uses a runtime ABNF/ASN.1 parser. This way you simply paste a schema definition verbatim from an RFC/other spec into an LDAP entry. This approach gets us basic syntax recognition/validation/equality matching without requiring any user-provided code at all, and one can compare at a glance what is in the server vs what is in the spec. I hadn't addressed provisions for ordering or substring matching yet; those concepts aren't captured in ABNF grammars so I was kind of blocked on what to do next.
-- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ --- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message.
