On 12/16/06, Howard Chu <[EMAIL PROTECTED]> wrote:
> ------------ 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.500Administrative > 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.
X.500 Administrative Model is the base model for several services of ApacheDS like: Collective Attributes, Access Control, Replication, Schema Subsystem and Triggers. If OpenLDAP also has plans on providing support for X.500 Adminsitrative Model (which is nice) we may come together for interoperability issues in the future. 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.
ApacheDS also already has a mechanish called Interceptors which allow plugins to be installed into the system easily, completely in an isolated manner. The services I mentioned in the previous paragraph and many more were implemented via this facility. Interceptors allows to control pre and post code segments on LDAP operations, filtering (altering) request attributes and responses. However, what makes LDAP Triggers special is that they are completely controlled over LDAP. They are simple String based objects that can be managed with a standard LDAP client. And also they leverage X.500 facilities like Subentries for selecting entries that Triggers are defined on. 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.
Of course, we do not suppose that SP will be used by regular users. Again, here, the gain is using standard LDAP protocol and clients. In the near future, we'll make the SP Call API completely independend of implementation language (using ASN.1). And also SP will have some sort of sandbox execution environment for security purposes. 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.
With the new schema subsystem, ApacheDS will store all schema elements (OC, AT, MR, SC etc) on the DIT and they will be easily loadable over LDAP via clients again. Cheers, -- Ersin --
-- 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 ldap@umich.edu as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message.
-- Ersin --- You are currently subscribed to ldap@umich.edu as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message.
