On 9/28/07, Stefan Zoerner <[EMAIL PROTECTED]> wrote: > > Alex Karasulu wrote: > > * Support for Scripting languages for Stored Procedures (e.g. > Groovy) > > > > > > This also would be really cool to have. We just need more participation > > on getting stored procedures > > implemented properly. It would be great if you could lend a hand if it > > interests you of course. > > It seems that it is not much code we talk about. I am interested.
This is great Stefan. <note> Stefan you and others insterested in this stuff may not be interested in these details below or how they will be managed by the stored procedure subsystem in the server. Wanting to do it with groovy should not have to force you to have to deal with these details. So please feel free to skip the material below. However at a minimum understanding these problems and their impact on you may help you a bit. </note> Incidentally I want to just list some of the issues we presently have on the table regarding our stored procedure implementation: 1). Security: Rights and Identity (owner verses invoker) Stored procedures can be invoked by anyone if access to the SP is allowed. The visibility of SP entries to invoker principals can be controlled with ACI. However if the invoker is different from the owner then with who's identity and authorization permissions do we execute the procedure? This is a big question we've been discussing for some time. We can continue to discuss this on this thread if people like but IMO the SP should execute with the authorization permissions of the owner with the identity of the invoker for auditing purposes. How to do this is entirely another question that our implementation must answer. 2). Security: Sandboxing SP Code SP code is code which needs to be sandboxed so code with lesser rights does not have the ability to execute internal code with administrator like rights. Today SPs in the server can do whatever they want no matter who invokes them. This is why they are turned off by default with the server as an insecure experimental feature. To take this to the next level we need to sandbox SP code and allow access to internal methods based on the rights and identity of the user. This is a really difficult problem to solve elegantly in ApacheDS as it stands today but it is a must. 3). SP Invocation: Procedure Qualification Right now we have an ExtendedOperation used to invoke stored procedures using qualified names based on the namespace of the procedure language. This is a questionable mechanism since it requires the user to know what the language of the implementation of the procedure is and how to qualify the procedure in that language. If a universal call specification is devised it can link language independent invocation requests to the proper language specific method. It would then be the job of the writer to add this call spec and not the job of the user to track which language the stored procedure was implemented in. 4). SP Invocation: Parameter Bindings This is connected to 3. The same extended operation allows invokers to provide parameters to the stored procedure. It would not be fun to have SPs without parameters. This opens up a slew of problems for us. First we need to define now a language independent means to specify parameters. ASN.1 does this nicely so we can leverage ASN.1 primitive types at first. ApacheDS can easily transform these types into the types expected by the implementation language of the SP. This however requires some primitive type bindings and the code to translate them. Right now the extended operation works with primitive Java types and serialized objects (I think but Ersin can confirm). This makes it so a C client cannot really invoke a SP implemented in Java unless it knows how to serialize java objects into a byte buffer. This is not really feasible so we need to specify some type bindings and use that instead of serializing objects. We cannot expect invokers from python, groovy, php, c, perl etc to have to know anything about Java. Invocation should not have be language dependent to allow for maximum flexibility. I'm adding these details btw to a the first draft (version 00) of an IETF draft submission. Alex
