2005/12/14, Marc Boorshtein <[EMAIL PROTECTED]>:
We want ApacheDS to grow up to enterprise ready directory, but also we want its modules are stripped out to be as small as it is considered embeddable. I don't think these two vision don't conflict to each other.
Yes, you're right. I agree. :)
Exactly. People don't use extended operations often. But what if users can define what they can do with extended operations very easily using their favorite script language? This will change the way people operate on the DIT.
It is just like RDBMS stored procedures. You can call stored procedures from your JDBC code, or you can just avoid the use of stored procedures. I think it depends on your situation. I think stored procedures are especially good for administrators who want to manage their DIT. Imagine that you can move too old entries to other partition which is more optimized for read-only access automatically every night. (Yes, we have to provide some scheduler here, or use other existing services not reinventing the wheel.)
You're right. But triggers are very useful for management purpose. For example, administrators will want to get notified via an SMS or an e-mail when an important entry is modified. This can be done easily by combining trigger and SP, and lessen the burden of management cost definitely.
We can use collective attributes in some cases, but what we want to change might be fulfilled only by bulk operations (e.g. partial string replacement)
HTH,
Trustin
-- > 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?
We want ApacheDS to grow up to enterprise ready directory, but also we want its modules are stripped out to be as small as it is considered embeddable. I don't think these two vision don't conflict to each other.
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.
Yes, you're right. I agree. :)
> 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.
Exactly. People don't use extended operations often. But what if users can define what they can do with extended operations very easily using their favorite script language? This will change the way people operate on the DIT.
It is just like RDBMS stored procedures. You can call stored procedures from your JDBC code, or you can just avoid the use of stored procedures. I think it depends on your situation. I think stored procedures are especially good for administrators who want to manage their DIT. Imagine that you can move too old entries to other partition which is more optimized for read-only access automatically every night. (Yes, we have to provide some scheduler here, or use other existing services not reinventing the wheel.)
> 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.
You're right. But triggers are very useful for management purpose. For example, administrators will want to get notified via an SMS or an e-mail when an important entry is modified. This can be done easily by combining trigger and SP, and lessen the burden of management cost definitely.
> 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?
We can use collective attributes in some cases, but what we want to change might be fulfilled only by bulk operations (e.g. partial string replacement)
HTH,
Trustin
what we call human nature is actually human habit
--
http://gleamynode.net/
