You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Ersin Er <er...@gmail.com> on 2005/12/10 13:22:44 UTC
[ApacheDS][SP] Stored Procedure Languages
Hi all,
We're working on adding DIT based stored procedure support to
ApacheDS. I'll give more details in the next days and I'll get your
ideas but now I request help about choosing a scripting language that
we can support. Our main focus is on supporting Java Byte Code and we
also want to design the API to allow adding new language
implementations. To achieve such a design we decided to implement one
more language which is possibly a scripting language.
We may consider Mozilla Rhino, Groovy, Jython or whatever else.. The
important point for our selection is that the language should be an
appropriate one for JNDI operations and it should also be as much as
close to Java type system.
Cheers,
--
Ersin
Re: [ApacheDS][SP] Stored Procedure Languages
Posted by Ersin Er <er...@gmail.com>.
On 12/11/05, Nick Faiz <ni...@atlassian.com> wrote:
> There's also JRuby - http://jruby.sourceforge.net/
>
> The site mentions it supports interaction with Java classes.
Infact all of the Java based scripting languages interact with Java
classes in some way but some of them may better fit to our needs.
> I haven't used it so I can't recommend it.
Thanks for interest.
> Cheers,
> Nick
>
>
>
> On 11/12/2005, at 9:04 AM, Marc Boorshtein wrote:
>
> > I'm sure there are plenty of very good scripting languages beyond
> > beanshell...that is simply the only one besides jython I had been
> > testing.
> >
> > marc
> >
> >
> > On 12/10/05, Ersin Er <er...@gmail.com> wrote:
> >> On 12/10/05, Marc Boorshtein <mb...@gmail.com> wrote:
> >>> Just a bit of advise, don't go with Jython unless you are willing to
> >>> do a lot of work dealing with pre-compiling code. As an interpreted
> >>> language it is EXCEEDINGLY slow. I found beanshell was acceptable
> >>> from an interpretive standpoint.
> >>
> >> Thank you very much Marc. I'll consider your advise.
> >>
> >> BeanShell is also supported by a JCP:
> >> http://www.jcp.org/en/jsr/detail?id=274
> >>
> >> I would really like to rely on "javax.script" but it's far away
> >> from today now:
> >> http://www.jcp.org/en/jsr/detail?id=223
> >>
> >> This article also gives some clues about advantages of BeanShell:
> >> http://www.artima.com/lejava/articles/beanshellP.html
> >>
> >> OK, BeanShell seems to be promising. We'll also examine others
> >> especially for JNDI and Java type system integration aspects.
> >>
> >>> marc
> >>>
> >>>
> >>> On 12/10/05, Ersin Er <er...@gmail.com> wrote:
> >>>> Hi Emmanuel,
> >>>>
> >>>> Thanks for response. The main reason I'm looking for a second
> >>>> language
> >>>> is to better design the API so that it's generic enough to support
> >>>> other languages. Considering the second language while designing
> >>>> the
> >>>> API helps to see what should be generic and what do not need to be.
> >>>>
> >>>> Jelly? No.. :-) (We're trying to make things easier.)
> >>>>
> >>>> --
> >>>> Ersin
> >>>>
> >>>> On 12/10/05, Emmanuel Lecharny <el...@gmail.com> wrote:
> >>>>> Hi Ersin,
> >>>>>
> >>>>> from my point of view, choose whatever langage that fit your
> >>>>> needs. As
> >>>>> the way you are going to interface this langage to Apache
> >>>>> Directory
> >>>>> Server is somehow generic, we will perfectly be able to
> >>>>> implement a
> >>>>> second langage if needed.
> >>>>>
> >>>>> Of course, if you were to chose Jelly, I will veto it ;)
> >>>>>
> >>>>> You could also investigate something like Janino
> >>>>> (http://www.janino.net/index.html#what) which is used
> >>>>> internally by
> >>>>> groovy.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Sat, 2005-12-10 at 14:22 +0200, Ersin Er wrote:
> >>>>>> Hi all,
> >>>>>>
> >>>>>> We're working on adding DIT based stored procedure support to
> >>>>>> ApacheDS. I'll give more details in the next days and I'll get
> >>>>>> your
> >>>>>> ideas but now I request help about choosing a scripting
> >>>>>> language that
> >>>>>> we can support. Our main focus is on supporting Java Byte Code
> >>>>>> and we
> >>>>>> also want to design the API to allow adding new language
> >>>>>> implementations. To achieve such a design we decided to
> >>>>>> implement one
> >>>>>> more language which is possibly a scripting language.
> >>>>>>
> >>>>>> We may consider Mozilla Rhino, Groovy, Jython or whatever
> >>>>>> else.. The
> >>>>>> important point for our selection is that the language should
> >>>>>> be an
> >>>>>> appropriate one for JNDI operations and it should also be as
> >>>>>> much as
> >>>>>> close to Java type system.
> >>>>>>
> >>>>>> Cheers,
> >>>>>> --
> >>>>>> Ersin
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Ersin
> >>>>
> >>>
> >>
> >>
> >> --
> >> Ersin
> >>
>
>
--
Ersin
Re: [ApacheDS][SP] Stored Procedure Languages
Posted by Nick Faiz <ni...@atlassian.com>.
There's also JRuby - http://jruby.sourceforge.net/
The site mentions it supports interaction with Java classes.
I haven't used it so I can't recommend it.
Cheers,
Nick
On 11/12/2005, at 9:04 AM, Marc Boorshtein wrote:
> I'm sure there are plenty of very good scripting languages beyond
> beanshell...that is simply the only one besides jython I had been
> testing.
>
> marc
>
>
> On 12/10/05, Ersin Er <er...@gmail.com> wrote:
>> On 12/10/05, Marc Boorshtein <mb...@gmail.com> wrote:
>>> Just a bit of advise, don't go with Jython unless you are willing to
>>> do a lot of work dealing with pre-compiling code. As an interpreted
>>> language it is EXCEEDINGLY slow. I found beanshell was acceptable
>>> from an interpretive standpoint.
>>
>> Thank you very much Marc. I'll consider your advise.
>>
>> BeanShell is also supported by a JCP:
>> http://www.jcp.org/en/jsr/detail?id=274
>>
>> I would really like to rely on "javax.script" but it's far away
>> from today now:
>> http://www.jcp.org/en/jsr/detail?id=223
>>
>> This article also gives some clues about advantages of BeanShell:
>> http://www.artima.com/lejava/articles/beanshellP.html
>>
>> OK, BeanShell seems to be promising. We'll also examine others
>> especially for JNDI and Java type system integration aspects.
>>
>>> marc
>>>
>>>
>>> On 12/10/05, Ersin Er <er...@gmail.com> wrote:
>>>> Hi Emmanuel,
>>>>
>>>> Thanks for response. The main reason I'm looking for a second
>>>> language
>>>> is to better design the API so that it's generic enough to support
>>>> other languages. Considering the second language while designing
>>>> the
>>>> API helps to see what should be generic and what do not need to be.
>>>>
>>>> Jelly? No.. :-) (We're trying to make things easier.)
>>>>
>>>> --
>>>> Ersin
>>>>
>>>> On 12/10/05, Emmanuel Lecharny <el...@gmail.com> wrote:
>>>>> Hi Ersin,
>>>>>
>>>>> from my point of view, choose whatever langage that fit your
>>>>> needs. As
>>>>> the way you are going to interface this langage to Apache
>>>>> Directory
>>>>> Server is somehow generic, we will perfectly be able to
>>>>> implement a
>>>>> second langage if needed.
>>>>>
>>>>> Of course, if you were to chose Jelly, I will veto it ;)
>>>>>
>>>>> You could also investigate something like Janino
>>>>> (http://www.janino.net/index.html#what) which is used
>>>>> internally by
>>>>> groovy.
>>>>>
>>>>>
>>>>>
>>>>> On Sat, 2005-12-10 at 14:22 +0200, Ersin Er wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> We're working on adding DIT based stored procedure support to
>>>>>> ApacheDS. I'll give more details in the next days and I'll get
>>>>>> your
>>>>>> ideas but now I request help about choosing a scripting
>>>>>> language that
>>>>>> we can support. Our main focus is on supporting Java Byte Code
>>>>>> and we
>>>>>> also want to design the API to allow adding new language
>>>>>> implementations. To achieve such a design we decided to
>>>>>> implement one
>>>>>> more language which is possibly a scripting language.
>>>>>>
>>>>>> We may consider Mozilla Rhino, Groovy, Jython or whatever
>>>>>> else.. The
>>>>>> important point for our selection is that the language should
>>>>>> be an
>>>>>> appropriate one for JNDI operations and it should also be as
>>>>>> much as
>>>>>> close to Java type system.
>>>>>>
>>>>>> Cheers,
>>>>>> --
>>>>>> Ersin
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Ersin
>>>>
>>>
>>
>>
>> --
>> Ersin
>>
Re: [ApacheDS][SP] Stored Procedure Languages
Posted by Marc Boorshtein <mb...@gmail.com>.
I'm sure there are plenty of very good scripting languages beyond
beanshell...that is simply the only one besides jython I had been
testing.
marc
On 12/10/05, Ersin Er <er...@gmail.com> wrote:
> On 12/10/05, Marc Boorshtein <mb...@gmail.com> wrote:
> > Just a bit of advise, don't go with Jython unless you are willing to
> > do a lot of work dealing with pre-compiling code. As an interpreted
> > language it is EXCEEDINGLY slow. I found beanshell was acceptable
> > from an interpretive standpoint.
>
> Thank you very much Marc. I'll consider your advise.
>
> BeanShell is also supported by a JCP:
> http://www.jcp.org/en/jsr/detail?id=274
>
> I would really like to rely on "javax.script" but it's far away from today now:
> http://www.jcp.org/en/jsr/detail?id=223
>
> This article also gives some clues about advantages of BeanShell:
> http://www.artima.com/lejava/articles/beanshellP.html
>
> OK, BeanShell seems to be promising. We'll also examine others
> especially for JNDI and Java type system integration aspects.
>
> > marc
> >
> >
> > On 12/10/05, Ersin Er <er...@gmail.com> wrote:
> > > Hi Emmanuel,
> > >
> > > Thanks for response. The main reason I'm looking for a second language
> > > is to better design the API so that it's generic enough to support
> > > other languages. Considering the second language while designing the
> > > API helps to see what should be generic and what do not need to be.
> > >
> > > Jelly? No.. :-) (We're trying to make things easier.)
> > >
> > > --
> > > Ersin
> > >
> > > On 12/10/05, Emmanuel Lecharny <el...@gmail.com> wrote:
> > > > Hi Ersin,
> > > >
> > > > from my point of view, choose whatever langage that fit your needs. As
> > > > the way you are going to interface this langage to Apache Directory
> > > > Server is somehow generic, we will perfectly be able to implement a
> > > > second langage if needed.
> > > >
> > > > Of course, if you were to chose Jelly, I will veto it ;)
> > > >
> > > > You could also investigate something like Janino
> > > > (http://www.janino.net/index.html#what) which is used internally by
> > > > groovy.
> > > >
> > > >
> > > >
> > > > On Sat, 2005-12-10 at 14:22 +0200, Ersin Er wrote:
> > > > > Hi all,
> > > > >
> > > > > We're working on adding DIT based stored procedure support to
> > > > > ApacheDS. I'll give more details in the next days and I'll get your
> > > > > ideas but now I request help about choosing a scripting language that
> > > > > we can support. Our main focus is on supporting Java Byte Code and we
> > > > > also want to design the API to allow adding new language
> > > > > implementations. To achieve such a design we decided to implement one
> > > > > more language which is possibly a scripting language.
> > > > >
> > > > > We may consider Mozilla Rhino, Groovy, Jython or whatever else.. The
> > > > > important point for our selection is that the language should be an
> > > > > appropriate one for JNDI operations and it should also be as much as
> > > > > close to Java type system.
> > > > >
> > > > > Cheers,
> > > > > --
> > > > > Ersin
> > > >
> > > >
> > >
> > >
> > > --
> > > Ersin
> > >
> >
>
>
> --
> Ersin
>
Re: [ApacheDS][SP] Stored Procedure Languages
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
See:
http://www.apache.org/foundation/records/minutes/2005/board_minutes_2005_08_17.txt
(Special Orders 6.B.)
The board has indirectly approved the use of Rhino through the
resolution found through the link above. Be sure to follow the
instructions contained in the resolution.
On 12.12.2005 10:16:52 Trustin Lee wrote:
> Hi all,
>
> 2005/12/12, Ersin Er <er...@gmail.com>:
> >
> > Hmm, OK. BeanShell seemed to be well integrated with Java but
> > performance is an important aspect of our choice. We many consider
> > using Mozilla Rhino.
>
>
> Rhino is a JavaScript engine with great performance and ease of use, but
> there's an issue with its license IIRC. There was a discussion on Rhino in
> legal-discuss@apache.org, but this issue was not closed because nobody gave
> the bottom line. I don't think it is because this issue is resolved; I've
> been reading legal-discuss list since it had started.
>
> If license becomes a problem, we could just use Groovy, which is more
> attractive option for Java developers.
>
> HTH,
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
Jeremias Maerki
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: [ApacheDS][SP] Stored Procedure Languages
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
See:
http://www.apache.org/foundation/records/minutes/2005/board_minutes_2005_08_17.txt
(Special Orders 6.B.)
The board has indirectly approved the use of Rhino through the
resolution found through the link above. Be sure to follow the
instructions contained in the resolution.
On 12.12.2005 10:16:52 Trustin Lee wrote:
> Hi all,
>
> 2005/12/12, Ersin Er <er...@gmail.com>:
> >
> > Hmm, OK. BeanShell seemed to be well integrated with Java but
> > performance is an important aspect of our choice. We many consider
> > using Mozilla Rhino.
>
>
> Rhino is a JavaScript engine with great performance and ease of use, but
> there's an issue with its license IIRC. There was a discussion on Rhino in
> legal-discuss@apache.org, but this issue was not closed because nobody gave
> the bottom line. I don't think it is because this issue is resolved; I've
> been reading legal-discuss list since it had started.
>
> If license becomes a problem, we could just use Groovy, which is more
> attractive option for Java developers.
>
> HTH,
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
Jeremias Maerki
Re: [ApacheDS][SP] Stored Procedure Languages
Posted by Ersin Er <er...@gmail.com>.
On 12/19/05, Trustin Lee <tr...@gmail.com> wrote:
> 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.)
Well, we'll have Quartz integration after SP support ;)
--
Ersin
Re: [ApacheDS][SP] Stored Procedure Languages
Posted by Trustin Lee <tr...@gmail.com>.
Hi MarC, :)
2005/12/14, Marc Boorshtein <mb...@gmail.com>:
>
> > 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/
Re: [ApacheDS][SP] Stored Procedure Languages
Posted by Marc Boorshtein <mb...@gmail.com>.
On 12/13/05, Alex Karasulu <ao...@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
Re: [ApacheDS][SP] Stored Procedure Languages
Posted by Alex Karasulu <ao...@bellsouth.net>.
Ersin, Mark,
>Alex may have some ideas about using Stored Procedures for better use
>cases in the future.
>
>
Before discussing use cases for stored procedures which in my opinion
can be infinite let me describe my view of stored procedures in LDAP as
they relate to extended operations.
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.
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.
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.
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)
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.
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.
Many things can be done with SPs. The sky is the limit or your
imagination. We'll see all sorts of use cases emerge.
Alex
Re: [ApacheDS][SP] Stored Procedure Languages
Posted by Ersin Er <er...@gmail.com>.
On 12/12/05, Marc Boorshtein <mb...@gmail.com> wrote:
> Well, thats not really a use case. For instance what is the use case
> for stored procs in a relational db? While there are many, the
> primary ones are:
>
> 1. Transaction Management - Being able to manage the business logic
> around a transaction in order to maintain the integrity of the data in
> the database.
>
> 2. Security - Often DBAs will only allow access to stored procs as
> opposed direct access to tables. It makes security that much easier.
>
> 3. Reporting - Often an SQL statement is not enough for a report
> (maybe some switching logic or parameter logic)
>
> There are more use-cases, but these are some of the most common.
> Which of these apply to directories though? The other question
> relates to the interface. Applications which interact with databases
> are coded for a particuler schema (tables, views, stored procs...)
> and so its reasonable to make the application call a stored procedure.
> Applications which hit directories for information are generally
> coded to either the ldapv3 standard or for a particuler directory or
> even a directory instance. While the extended operation is a part of
> the ldapv3 standard, there aren't many applications that use them.
If there are not many use cases for Extended Operation in LDAP then
this means to some degree there are not much use cases for Stored
Procedures as Extended Operations. What we provide is a more flexible
mechanism which provides users the ability to define their own
extended operations. Use cases are limited with users' thougths, aims.
Stored Procedures will be mainly used for Triggers and Job Scheduling
in ApacheDS Server. And also a SP does not have to be published as a
StoredProcedureExtendedOperation. This is just a choice.
Alex may have some ideas about using Stored Procedures for better use
cases in the future.
Thanks.
> Marc
>
> On 12/12/05, Ersin Er <er...@gmail.com> wrote:
> > On 12/12/05, Marc Boorshtein <mb...@gmail.com> wrote:
> > > Interesting. So what use-cases currently exist for the "Extended
> > > Operation" model for Stored Procs in a directory?
> >
> > What ever you want.. For example, for some run time configurations,
> > for some administrative scripts for collecting some statistics.. There
> > can be much more..
> >
> > > Marc
> > >
> > > On 12/12/05, Ersin Er <er...@gmail.com> wrote:
> > > > On 12/12/05, Marc Boorshtein <mb...@gmail.com> wrote:
> > > > > Sorry, should have said "Stored Procedure" or script. Will the
> > > > > scripts be executed by a particuler operation (ie an add is executed
> > > > > which executes a script) or will it be executed manually by some
> > > > > external mechanism?
> > > >
> > > > Oh OK. Stored Procedures provide a great selection of usages. First
> > > > what we do to provide excutable code in the server is publishing these
> > > > stored procedures as extended operations. In fact we have only one
> > > > generic extended operation (say StoredProcedureExtendedOperation)
> > > > which accepts a call specification and executes the appropriate SP on
> > > > the server. Briefly, we are providing users the ability to "define
> > > > their own extended operations."
> > > >
> > > > SPs will also be used for Triggers. Triggers will be able to fire SPs
> > > > only. Say an Add operation will fire a SP (which will probably have to
> > > > implement an interface like AfterAddStoredProc) and appropriate
> > > > parameters in that context will be passed to the SP (via the method
> > > > forced by the interface).
> > > >
> > > > There are other usages of SP like scheduled tasks, etc. Finally I can
> > > > say that a stored procedure can be executed by a user or by an
> > > > operation automatically. This changes up to the context in which we
> > > > use them. But the Extended Operation mechanism is the main objective
> > > > now.
> > > >
> > > > Thanks for interest.
> > > >
> > > > > Marc
> > > > >
> > > > > On 12/12/05, Ersin Er <er...@gmail.com> wrote:
> > > > > > On 12/12/05, Marc Boorshtein <mb...@gmail.com> wrote:
> > > > > > > Performance will probably be an issue with almost any scripting
> > > > > > > language that provides some more dynamic capabilities then java.
> > > > > >
> > > > > > Of course. Just trying to choose a reasoable one.
> > > > > >
> > > > > > > Also, what are you planning to use as the mapping model? For
> > > > > > > instance, will it be a single method for eac operation or a method for
> > > > > > > the input and one for the output?
> > > > > >
> > > > > > I'm not sure I exactly understand what you mean by mapping here. We
> > > > > > have DIT based Java classes whose only one static method can be called
> > > > > > as a stored procedure at a time. For scripting languages we may force
> > > > > > the script (again in the DIT) to have a function/method with certain
> > > > > > name (in case we cannot use reflection here) or we may use the script
> > > > > > as a whole. And for parameters we'll always use Java objects (and
> > > > > > primitives) and we will wrap them with any method required by the
> > > > > > scripting language and put in a context (as required by the scripting
> > > > > > language) to be passed to the script.
> > > > > >
> > > > > > > Marc
> > > > > > >
> > > > > > > On 12/12/05, Trustin Lee <tr...@gmail.com> wrote:
> > > > > > > > Hi all,
> > > > > > > >
> > > > > > > > 2005/12/12, Ersin Er <er...@gmail.com>:
> > > > > > > > > Hmm, OK. BeanShell seemed to be well integrated with Java but
> > > > > > > > > performance is an important aspect of our choice. We many consider
> > > > > > > > > using Mozilla Rhino.
> > > > > > > >
> > > > > > > > Rhino is a JavaScript engine with great performance and ease of use, but
> > > > > > > > there's an issue with its license IIRC. There was a discussion on Rhino in
> > > > > > > > legal-discuss@apache.org, but this issue was not closed because nobody gave
> > > > > > > > the bottom line. I don't think it is because this issue is resolved; I've
> > > > > > > > been reading legal-discuss list since it had started.
> > > > > > > >
> > > > > > > > If license becomes a problem, we could just use Groovy, which is more
> > > > > > > > attractive option for Java developers.
> > > > > > > >
> > > > > > > > HTH,
> > > > > > > > Trustin
> > > > > > > > --
> > > > > > > > what we call human nature is actually human habit
> > > > > > > > --
> > > > > > > > http://gleamynode.net/
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Ersin
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Ersin
> > > >
> > >
> >
> >
> > --
> > Ersin
> >
>
--
Ersin
Re: [ApacheDS][SP] Stored Procedure Languages
Posted by Marc Boorshtein <mb...@gmail.com>.
Well, thats not really a use case. For instance what is the use case
for stored procs in a relational db? While there are many, the
primary ones are:
1. Transaction Management - Being able to manage the business logic
around a transaction in order to maintain the integrity of the data in
the database.
2. Security - Often DBAs will only allow access to stored procs as
opposed direct access to tables. It makes security that much easier.
3. Reporting - Often an SQL statement is not enough for a report
(maybe some switching logic or parameter logic)
There are more use-cases, but these are some of the most common.
Which of these apply to directories though? The other question
relates to the interface. Applications which interact with databases
are coded for a particuler schema (tables, views, stored procs...)
and so its reasonable to make the application call a stored procedure.
Applications which hit directories for information are generally
coded to either the ldapv3 standard or for a particuler directory or
even a directory instance. While the extended operation is a part of
the ldapv3 standard, there aren't many applications that use them.
Marc
On 12/12/05, Ersin Er <er...@gmail.com> wrote:
> On 12/12/05, Marc Boorshtein <mb...@gmail.com> wrote:
> > Interesting. So what use-cases currently exist for the "Extended
> > Operation" model for Stored Procs in a directory?
>
> What ever you want.. For example, for some run time configurations,
> for some administrative scripts for collecting some statistics.. There
> can be much more..
>
> > Marc
> >
> > On 12/12/05, Ersin Er <er...@gmail.com> wrote:
> > > On 12/12/05, Marc Boorshtein <mb...@gmail.com> wrote:
> > > > Sorry, should have said "Stored Procedure" or script. Will the
> > > > scripts be executed by a particuler operation (ie an add is executed
> > > > which executes a script) or will it be executed manually by some
> > > > external mechanism?
> > >
> > > Oh OK. Stored Procedures provide a great selection of usages. First
> > > what we do to provide excutable code in the server is publishing these
> > > stored procedures as extended operations. In fact we have only one
> > > generic extended operation (say StoredProcedureExtendedOperation)
> > > which accepts a call specification and executes the appropriate SP on
> > > the server. Briefly, we are providing users the ability to "define
> > > their own extended operations."
> > >
> > > SPs will also be used for Triggers. Triggers will be able to fire SPs
> > > only. Say an Add operation will fire a SP (which will probably have to
> > > implement an interface like AfterAddStoredProc) and appropriate
> > > parameters in that context will be passed to the SP (via the method
> > > forced by the interface).
> > >
> > > There are other usages of SP like scheduled tasks, etc. Finally I can
> > > say that a stored procedure can be executed by a user or by an
> > > operation automatically. This changes up to the context in which we
> > > use them. But the Extended Operation mechanism is the main objective
> > > now.
> > >
> > > Thanks for interest.
> > >
> > > > Marc
> > > >
> > > > On 12/12/05, Ersin Er <er...@gmail.com> wrote:
> > > > > On 12/12/05, Marc Boorshtein <mb...@gmail.com> wrote:
> > > > > > Performance will probably be an issue with almost any scripting
> > > > > > language that provides some more dynamic capabilities then java.
> > > > >
> > > > > Of course. Just trying to choose a reasoable one.
> > > > >
> > > > > > Also, what are you planning to use as the mapping model? For
> > > > > > instance, will it be a single method for eac operation or a method for
> > > > > > the input and one for the output?
> > > > >
> > > > > I'm not sure I exactly understand what you mean by mapping here. We
> > > > > have DIT based Java classes whose only one static method can be called
> > > > > as a stored procedure at a time. For scripting languages we may force
> > > > > the script (again in the DIT) to have a function/method with certain
> > > > > name (in case we cannot use reflection here) or we may use the script
> > > > > as a whole. And for parameters we'll always use Java objects (and
> > > > > primitives) and we will wrap them with any method required by the
> > > > > scripting language and put in a context (as required by the scripting
> > > > > language) to be passed to the script.
> > > > >
> > > > > > Marc
> > > > > >
> > > > > > On 12/12/05, Trustin Lee <tr...@gmail.com> wrote:
> > > > > > > Hi all,
> > > > > > >
> > > > > > > 2005/12/12, Ersin Er <er...@gmail.com>:
> > > > > > > > Hmm, OK. BeanShell seemed to be well integrated with Java but
> > > > > > > > performance is an important aspect of our choice. We many consider
> > > > > > > > using Mozilla Rhino.
> > > > > > >
> > > > > > > Rhino is a JavaScript engine with great performance and ease of use, but
> > > > > > > there's an issue with its license IIRC. There was a discussion on Rhino in
> > > > > > > legal-discuss@apache.org, but this issue was not closed because nobody gave
> > > > > > > the bottom line. I don't think it is because this issue is resolved; I've
> > > > > > > been reading legal-discuss list since it had started.
> > > > > > >
> > > > > > > If license becomes a problem, we could just use Groovy, which is more
> > > > > > > attractive option for Java developers.
> > > > > > >
> > > > > > > HTH,
> > > > > > > Trustin
> > > > > > > --
> > > > > > > what we call human nature is actually human habit
> > > > > > > --
> > > > > > > http://gleamynode.net/
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Ersin
> > > > >
> > > >
> > >
> > >
> > > --
> > > Ersin
> > >
> >
>
>
> --
> Ersin
>
Re: [ApacheDS][SP] Stored Procedure Languages
Posted by Ersin Er <er...@gmail.com>.
On 12/12/05, Marc Boorshtein <mb...@gmail.com> wrote:
> Interesting. So what use-cases currently exist for the "Extended
> Operation" model for Stored Procs in a directory?
What ever you want.. For example, for some run time configurations,
for some administrative scripts for collecting some statistics.. There
can be much more..
> Marc
>
> On 12/12/05, Ersin Er <er...@gmail.com> wrote:
> > On 12/12/05, Marc Boorshtein <mb...@gmail.com> wrote:
> > > Sorry, should have said "Stored Procedure" or script. Will the
> > > scripts be executed by a particuler operation (ie an add is executed
> > > which executes a script) or will it be executed manually by some
> > > external mechanism?
> >
> > Oh OK. Stored Procedures provide a great selection of usages. First
> > what we do to provide excutable code in the server is publishing these
> > stored procedures as extended operations. In fact we have only one
> > generic extended operation (say StoredProcedureExtendedOperation)
> > which accepts a call specification and executes the appropriate SP on
> > the server. Briefly, we are providing users the ability to "define
> > their own extended operations."
> >
> > SPs will also be used for Triggers. Triggers will be able to fire SPs
> > only. Say an Add operation will fire a SP (which will probably have to
> > implement an interface like AfterAddStoredProc) and appropriate
> > parameters in that context will be passed to the SP (via the method
> > forced by the interface).
> >
> > There are other usages of SP like scheduled tasks, etc. Finally I can
> > say that a stored procedure can be executed by a user or by an
> > operation automatically. This changes up to the context in which we
> > use them. But the Extended Operation mechanism is the main objective
> > now.
> >
> > Thanks for interest.
> >
> > > Marc
> > >
> > > On 12/12/05, Ersin Er <er...@gmail.com> wrote:
> > > > On 12/12/05, Marc Boorshtein <mb...@gmail.com> wrote:
> > > > > Performance will probably be an issue with almost any scripting
> > > > > language that provides some more dynamic capabilities then java.
> > > >
> > > > Of course. Just trying to choose a reasoable one.
> > > >
> > > > > Also, what are you planning to use as the mapping model? For
> > > > > instance, will it be a single method for eac operation or a method for
> > > > > the input and one for the output?
> > > >
> > > > I'm not sure I exactly understand what you mean by mapping here. We
> > > > have DIT based Java classes whose only one static method can be called
> > > > as a stored procedure at a time. For scripting languages we may force
> > > > the script (again in the DIT) to have a function/method with certain
> > > > name (in case we cannot use reflection here) or we may use the script
> > > > as a whole. And for parameters we'll always use Java objects (and
> > > > primitives) and we will wrap them with any method required by the
> > > > scripting language and put in a context (as required by the scripting
> > > > language) to be passed to the script.
> > > >
> > > > > Marc
> > > > >
> > > > > On 12/12/05, Trustin Lee <tr...@gmail.com> wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > 2005/12/12, Ersin Er <er...@gmail.com>:
> > > > > > > Hmm, OK. BeanShell seemed to be well integrated with Java but
> > > > > > > performance is an important aspect of our choice. We many consider
> > > > > > > using Mozilla Rhino.
> > > > > >
> > > > > > Rhino is a JavaScript engine with great performance and ease of use, but
> > > > > > there's an issue with its license IIRC. There was a discussion on Rhino in
> > > > > > legal-discuss@apache.org, but this issue was not closed because nobody gave
> > > > > > the bottom line. I don't think it is because this issue is resolved; I've
> > > > > > been reading legal-discuss list since it had started.
> > > > > >
> > > > > > If license becomes a problem, we could just use Groovy, which is more
> > > > > > attractive option for Java developers.
> > > > > >
> > > > > > HTH,
> > > > > > Trustin
> > > > > > --
> > > > > > what we call human nature is actually human habit
> > > > > > --
> > > > > > http://gleamynode.net/
> > > > >
> > > >
> > > >
> > > > --
> > > > Ersin
> > > >
> > >
> >
> >
> > --
> > Ersin
> >
>
--
Ersin
Re: [ApacheDS][SP] Stored Procedure Languages
Posted by Marc Boorshtein <mb...@gmail.com>.
Interesting. So what use-cases currently exist for the "Extended
Operation" model for Stored Procs in a directory?
Marc
On 12/12/05, Ersin Er <er...@gmail.com> wrote:
> On 12/12/05, Marc Boorshtein <mb...@gmail.com> wrote:
> > Sorry, should have said "Stored Procedure" or script. Will the
> > scripts be executed by a particuler operation (ie an add is executed
> > which executes a script) or will it be executed manually by some
> > external mechanism?
>
> Oh OK. Stored Procedures provide a great selection of usages. First
> what we do to provide excutable code in the server is publishing these
> stored procedures as extended operations. In fact we have only one
> generic extended operation (say StoredProcedureExtendedOperation)
> which accepts a call specification and executes the appropriate SP on
> the server. Briefly, we are providing users the ability to "define
> their own extended operations."
>
> SPs will also be used for Triggers. Triggers will be able to fire SPs
> only. Say an Add operation will fire a SP (which will probably have to
> implement an interface like AfterAddStoredProc) and appropriate
> parameters in that context will be passed to the SP (via the method
> forced by the interface).
>
> There are other usages of SP like scheduled tasks, etc. Finally I can
> say that a stored procedure can be executed by a user or by an
> operation automatically. This changes up to the context in which we
> use them. But the Extended Operation mechanism is the main objective
> now.
>
> Thanks for interest.
>
> > Marc
> >
> > On 12/12/05, Ersin Er <er...@gmail.com> wrote:
> > > On 12/12/05, Marc Boorshtein <mb...@gmail.com> wrote:
> > > > Performance will probably be an issue with almost any scripting
> > > > language that provides some more dynamic capabilities then java.
> > >
> > > Of course. Just trying to choose a reasoable one.
> > >
> > > > Also, what are you planning to use as the mapping model? For
> > > > instance, will it be a single method for eac operation or a method for
> > > > the input and one for the output?
> > >
> > > I'm not sure I exactly understand what you mean by mapping here. We
> > > have DIT based Java classes whose only one static method can be called
> > > as a stored procedure at a time. For scripting languages we may force
> > > the script (again in the DIT) to have a function/method with certain
> > > name (in case we cannot use reflection here) or we may use the script
> > > as a whole. And for parameters we'll always use Java objects (and
> > > primitives) and we will wrap them with any method required by the
> > > scripting language and put in a context (as required by the scripting
> > > language) to be passed to the script.
> > >
> > > > Marc
> > > >
> > > > On 12/12/05, Trustin Lee <tr...@gmail.com> wrote:
> > > > > Hi all,
> > > > >
> > > > > 2005/12/12, Ersin Er <er...@gmail.com>:
> > > > > > Hmm, OK. BeanShell seemed to be well integrated with Java but
> > > > > > performance is an important aspect of our choice. We many consider
> > > > > > using Mozilla Rhino.
> > > > >
> > > > > Rhino is a JavaScript engine with great performance and ease of use, but
> > > > > there's an issue with its license IIRC. There was a discussion on Rhino in
> > > > > legal-discuss@apache.org, but this issue was not closed because nobody gave
> > > > > the bottom line. I don't think it is because this issue is resolved; I've
> > > > > been reading legal-discuss list since it had started.
> > > > >
> > > > > If license becomes a problem, we could just use Groovy, which is more
> > > > > attractive option for Java developers.
> > > > >
> > > > > HTH,
> > > > > Trustin
> > > > > --
> > > > > what we call human nature is actually human habit
> > > > > --
> > > > > http://gleamynode.net/
> > > >
> > >
> > >
> > > --
> > > Ersin
> > >
> >
>
>
> --
> Ersin
>
Re: [ApacheDS][SP] Stored Procedure Languages
Posted by Ersin Er <er...@gmail.com>.
On 12/12/05, Marc Boorshtein <mb...@gmail.com> wrote:
> Sorry, should have said "Stored Procedure" or script. Will the
> scripts be executed by a particuler operation (ie an add is executed
> which executes a script) or will it be executed manually by some
> external mechanism?
Oh OK. Stored Procedures provide a great selection of usages. First
what we do to provide excutable code in the server is publishing these
stored procedures as extended operations. In fact we have only one
generic extended operation (say StoredProcedureExtendedOperation)
which accepts a call specification and executes the appropriate SP on
the server. Briefly, we are providing users the ability to "define
their own extended operations."
SPs will also be used for Triggers. Triggers will be able to fire SPs
only. Say an Add operation will fire a SP (which will probably have to
implement an interface like AfterAddStoredProc) and appropriate
parameters in that context will be passed to the SP (via the method
forced by the interface).
There are other usages of SP like scheduled tasks, etc. Finally I can
say that a stored procedure can be executed by a user or by an
operation automatically. This changes up to the context in which we
use them. But the Extended Operation mechanism is the main objective
now.
Thanks for interest.
> Marc
>
> On 12/12/05, Ersin Er <er...@gmail.com> wrote:
> > On 12/12/05, Marc Boorshtein <mb...@gmail.com> wrote:
> > > Performance will probably be an issue with almost any scripting
> > > language that provides some more dynamic capabilities then java.
> >
> > Of course. Just trying to choose a reasoable one.
> >
> > > Also, what are you planning to use as the mapping model? For
> > > instance, will it be a single method for eac operation or a method for
> > > the input and one for the output?
> >
> > I'm not sure I exactly understand what you mean by mapping here. We
> > have DIT based Java classes whose only one static method can be called
> > as a stored procedure at a time. For scripting languages we may force
> > the script (again in the DIT) to have a function/method with certain
> > name (in case we cannot use reflection here) or we may use the script
> > as a whole. And for parameters we'll always use Java objects (and
> > primitives) and we will wrap them with any method required by the
> > scripting language and put in a context (as required by the scripting
> > language) to be passed to the script.
> >
> > > Marc
> > >
> > > On 12/12/05, Trustin Lee <tr...@gmail.com> wrote:
> > > > Hi all,
> > > >
> > > > 2005/12/12, Ersin Er <er...@gmail.com>:
> > > > > Hmm, OK. BeanShell seemed to be well integrated with Java but
> > > > > performance is an important aspect of our choice. We many consider
> > > > > using Mozilla Rhino.
> > > >
> > > > Rhino is a JavaScript engine with great performance and ease of use, but
> > > > there's an issue with its license IIRC. There was a discussion on Rhino in
> > > > legal-discuss@apache.org, but this issue was not closed because nobody gave
> > > > the bottom line. I don't think it is because this issue is resolved; I've
> > > > been reading legal-discuss list since it had started.
> > > >
> > > > If license becomes a problem, we could just use Groovy, which is more
> > > > attractive option for Java developers.
> > > >
> > > > HTH,
> > > > Trustin
> > > > --
> > > > what we call human nature is actually human habit
> > > > --
> > > > http://gleamynode.net/
> > >
> >
> >
> > --
> > Ersin
> >
>
--
Ersin
Re: [ApacheDS][SP] Stored Procedure Languages
Posted by Marc Boorshtein <mb...@gmail.com>.
Sorry, should have said "Stored Procedure" or script. Will the
scripts be executed by a particuler operation (ie an add is executed
which executes a script) or will it be executed manually by some
external mechanism?
Marc
On 12/12/05, Ersin Er <er...@gmail.com> wrote:
> On 12/12/05, Marc Boorshtein <mb...@gmail.com> wrote:
> > Performance will probably be an issue with almost any scripting
> > language that provides some more dynamic capabilities then java.
>
> Of course. Just trying to choose a reasoable one.
>
> > Also, what are you planning to use as the mapping model? For
> > instance, will it be a single method for eac operation or a method for
> > the input and one for the output?
>
> I'm not sure I exactly understand what you mean by mapping here. We
> have DIT based Java classes whose only one static method can be called
> as a stored procedure at a time. For scripting languages we may force
> the script (again in the DIT) to have a function/method with certain
> name (in case we cannot use reflection here) or we may use the script
> as a whole. And for parameters we'll always use Java objects (and
> primitives) and we will wrap them with any method required by the
> scripting language and put in a context (as required by the scripting
> language) to be passed to the script.
>
> > Marc
> >
> > On 12/12/05, Trustin Lee <tr...@gmail.com> wrote:
> > > Hi all,
> > >
> > > 2005/12/12, Ersin Er <er...@gmail.com>:
> > > > Hmm, OK. BeanShell seemed to be well integrated with Java but
> > > > performance is an important aspect of our choice. We many consider
> > > > using Mozilla Rhino.
> > >
> > > Rhino is a JavaScript engine with great performance and ease of use, but
> > > there's an issue with its license IIRC. There was a discussion on Rhino in
> > > legal-discuss@apache.org, but this issue was not closed because nobody gave
> > > the bottom line. I don't think it is because this issue is resolved; I've
> > > been reading legal-discuss list since it had started.
> > >
> > > If license becomes a problem, we could just use Groovy, which is more
> > > attractive option for Java developers.
> > >
> > > HTH,
> > > Trustin
> > > --
> > > what we call human nature is actually human habit
> > > --
> > > http://gleamynode.net/
> >
>
>
> --
> Ersin
>
Re: [ApacheDS][SP] Stored Procedure Languages
Posted by Ersin Er <er...@gmail.com>.
On 12/12/05, Marc Boorshtein <mb...@gmail.com> wrote:
> Performance will probably be an issue with almost any scripting
> language that provides some more dynamic capabilities then java.
Of course. Just trying to choose a reasoable one.
> Also, what are you planning to use as the mapping model? For
> instance, will it be a single method for eac operation or a method for
> the input and one for the output?
I'm not sure I exactly understand what you mean by mapping here. We
have DIT based Java classes whose only one static method can be called
as a stored procedure at a time. For scripting languages we may force
the script (again in the DIT) to have a function/method with certain
name (in case we cannot use reflection here) or we may use the script
as a whole. And for parameters we'll always use Java objects (and
primitives) and we will wrap them with any method required by the
scripting language and put in a context (as required by the scripting
language) to be passed to the script.
> Marc
>
> On 12/12/05, Trustin Lee <tr...@gmail.com> wrote:
> > Hi all,
> >
> > 2005/12/12, Ersin Er <er...@gmail.com>:
> > > Hmm, OK. BeanShell seemed to be well integrated with Java but
> > > performance is an important aspect of our choice. We many consider
> > > using Mozilla Rhino.
> >
> > Rhino is a JavaScript engine with great performance and ease of use, but
> > there's an issue with its license IIRC. There was a discussion on Rhino in
> > legal-discuss@apache.org, but this issue was not closed because nobody gave
> > the bottom line. I don't think it is because this issue is resolved; I've
> > been reading legal-discuss list since it had started.
> >
> > If license becomes a problem, we could just use Groovy, which is more
> > attractive option for Java developers.
> >
> > HTH,
> > Trustin
> > --
> > what we call human nature is actually human habit
> > --
> > http://gleamynode.net/
>
--
Ersin
Re: [ApacheDS][SP] Stored Procedure Languages
Posted by Marc Boorshtein <mb...@gmail.com>.
Performance will probably be an issue with almost any scripting
language that provides some more dynamic capabilities then java. Take
Jython (I don't know the inner workings of BeanShell) as an example.
In order to support the flexability of Python on the JVM, there is a
LOT of overhead. Even if you compile the Jython to bytecode, each
line of the python script is still interpreted, just in a Java class
(you can actually see the .java source once you compile a jython
class). So at least for this discussion I think it would be fair to
make the term "performance" relative. Often when choosing between a
"script" and a "plugin" when deploying any kind of virtual directory,
I will usually build a script in order to prototype an idea, but will
re-write it as a plugin before going into production (unless the
script was VERY basic).
Also, what are you planning to use as the mapping model? For
instance, will it be a single method for eac operation or a method for
the input and one for the output?
Marc
On 12/12/05, Trustin Lee <tr...@gmail.com> wrote:
> Hi all,
>
> 2005/12/12, Ersin Er <er...@gmail.com>:
> > Hmm, OK. BeanShell seemed to be well integrated with Java but
> > performance is an important aspect of our choice. We many consider
> > using Mozilla Rhino.
>
> Rhino is a JavaScript engine with great performance and ease of use, but
> there's an issue with its license IIRC. There was a discussion on Rhino in
> legal-discuss@apache.org, but this issue was not closed because nobody gave
> the bottom line. I don't think it is because this issue is resolved; I've
> been reading legal-discuss list since it had started.
>
> If license becomes a problem, we could just use Groovy, which is more
> attractive option for Java developers.
>
> HTH,
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
Re: [ApacheDS][SP] Stored Procedure Languages
Posted by Trustin Lee <tr...@gmail.com>.
Hi all,
2005/12/12, Ersin Er <er...@gmail.com>:
>
> Hmm, OK. BeanShell seemed to be well integrated with Java but
> performance is an important aspect of our choice. We many consider
> using Mozilla Rhino.
Rhino is a JavaScript engine with great performance and ease of use, but
there's an issue with its license IIRC. There was a discussion on Rhino in
legal-discuss@apache.org, but this issue was not closed because nobody gave
the bottom line. I don't think it is because this issue is resolved; I've
been reading legal-discuss list since it had started.
If license becomes a problem, we could just use Groovy, which is more
attractive option for Java developers.
HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [ApacheDS][SP] Stored Procedure Languages
Posted by Trustin Lee <tr...@gmail.com>.
Hi all,
2005/12/12, Ersin Er <er...@gmail.com>:
>
> Hmm, OK. BeanShell seemed to be well integrated with Java but
> performance is an important aspect of our choice. We many consider
> using Mozilla Rhino.
Rhino is a JavaScript engine with great performance and ease of use, but
there's an issue with its license IIRC. There was a discussion on Rhino in
legal-discuss@apache.org, but this issue was not closed because nobody gave
the bottom line. I don't think it is because this issue is resolved; I've
been reading legal-discuss list since it had started.
If license becomes a problem, we could just use Groovy, which is more
attractive option for Java developers.
HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [ApacheDS][SP] Stored Procedure Languages
Posted by Ersin Er <er...@gmail.com>.
On 12/12/05, Julien Vermillard <jv...@archean.fr> wrote:
> Greetings
>
> I use Beanshell a lot in my applications and I have really serious
> performance problems. Except for things ran only once, I whould avoid it
> like the pest.
Hmm, OK. BeanShell seemed to be well integrated with Java but
performance is an important aspect of our choice. We many consider
using Mozilla Rhino.
> Julien
Thanks.
--
Ersin
Re: [ApacheDS][SP] Stored Procedure Languages
Posted by Julien Vermillard <jv...@archean.fr>.
Greetings
I use Beanshell a lot in my applications and I have really serious
performance problems. Except for things ran only once, I whould avoid it
like the pest.
Julien
Re: [ApacheDS][SP] Stored Procedure Languages
Posted by Ersin Er <er...@gmail.com>.
On 12/10/05, Marc Boorshtein <mb...@gmail.com> wrote:
> Just a bit of advise, don't go with Jython unless you are willing to
> do a lot of work dealing with pre-compiling code. As an interpreted
> language it is EXCEEDINGLY slow. I found beanshell was acceptable
> from an interpretive standpoint.
Thank you very much Marc. I'll consider your advise.
BeanShell is also supported by a JCP:
http://www.jcp.org/en/jsr/detail?id=274
I would really like to rely on "javax.script" but it's far away from today now:
http://www.jcp.org/en/jsr/detail?id=223
This article also gives some clues about advantages of BeanShell:
http://www.artima.com/lejava/articles/beanshellP.html
OK, BeanShell seems to be promising. We'll also examine others
especially for JNDI and Java type system integration aspects.
> marc
>
>
> On 12/10/05, Ersin Er <er...@gmail.com> wrote:
> > Hi Emmanuel,
> >
> > Thanks for response. The main reason I'm looking for a second language
> > is to better design the API so that it's generic enough to support
> > other languages. Considering the second language while designing the
> > API helps to see what should be generic and what do not need to be.
> >
> > Jelly? No.. :-) (We're trying to make things easier.)
> >
> > --
> > Ersin
> >
> > On 12/10/05, Emmanuel Lecharny <el...@gmail.com> wrote:
> > > Hi Ersin,
> > >
> > > from my point of view, choose whatever langage that fit your needs. As
> > > the way you are going to interface this langage to Apache Directory
> > > Server is somehow generic, we will perfectly be able to implement a
> > > second langage if needed.
> > >
> > > Of course, if you were to chose Jelly, I will veto it ;)
> > >
> > > You could also investigate something like Janino
> > > (http://www.janino.net/index.html#what) which is used internally by
> > > groovy.
> > >
> > >
> > >
> > > On Sat, 2005-12-10 at 14:22 +0200, Ersin Er wrote:
> > > > Hi all,
> > > >
> > > > We're working on adding DIT based stored procedure support to
> > > > ApacheDS. I'll give more details in the next days and I'll get your
> > > > ideas but now I request help about choosing a scripting language that
> > > > we can support. Our main focus is on supporting Java Byte Code and we
> > > > also want to design the API to allow adding new language
> > > > implementations. To achieve such a design we decided to implement one
> > > > more language which is possibly a scripting language.
> > > >
> > > > We may consider Mozilla Rhino, Groovy, Jython or whatever else.. The
> > > > important point for our selection is that the language should be an
> > > > appropriate one for JNDI operations and it should also be as much as
> > > > close to Java type system.
> > > >
> > > > Cheers,
> > > > --
> > > > Ersin
> > >
> > >
> >
> >
> > --
> > Ersin
> >
>
--
Ersin
Re: [ApacheDS][SP] Stored Procedure Languages
Posted by Marc Boorshtein <mb...@gmail.com>.
Just a bit of advise, don't go with Jython unless you are willing to
do a lot of work dealing with pre-compiling code. As an interpreted
language it is EXCEEDINGLY slow. I found beanshell was acceptable
from an interpretive standpoint.
marc
On 12/10/05, Ersin Er <er...@gmail.com> wrote:
> Hi Emmanuel,
>
> Thanks for response. The main reason I'm looking for a second language
> is to better design the API so that it's generic enough to support
> other languages. Considering the second language while designing the
> API helps to see what should be generic and what do not need to be.
>
> Jelly? No.. :-) (We're trying to make things easier.)
>
> --
> Ersin
>
> On 12/10/05, Emmanuel Lecharny <el...@gmail.com> wrote:
> > Hi Ersin,
> >
> > from my point of view, choose whatever langage that fit your needs. As
> > the way you are going to interface this langage to Apache Directory
> > Server is somehow generic, we will perfectly be able to implement a
> > second langage if needed.
> >
> > Of course, if you were to chose Jelly, I will veto it ;)
> >
> > You could also investigate something like Janino
> > (http://www.janino.net/index.html#what) which is used internally by
> > groovy.
> >
> >
> >
> > On Sat, 2005-12-10 at 14:22 +0200, Ersin Er wrote:
> > > Hi all,
> > >
> > > We're working on adding DIT based stored procedure support to
> > > ApacheDS. I'll give more details in the next days and I'll get your
> > > ideas but now I request help about choosing a scripting language that
> > > we can support. Our main focus is on supporting Java Byte Code and we
> > > also want to design the API to allow adding new language
> > > implementations. To achieve such a design we decided to implement one
> > > more language which is possibly a scripting language.
> > >
> > > We may consider Mozilla Rhino, Groovy, Jython or whatever else.. The
> > > important point for our selection is that the language should be an
> > > appropriate one for JNDI operations and it should also be as much as
> > > close to Java type system.
> > >
> > > Cheers,
> > > --
> > > Ersin
> >
> >
>
>
> --
> Ersin
>
Re: [ApacheDS][SP] Stored Procedure Languages
Posted by Ersin Er <er...@gmail.com>.
Hi Emmanuel,
Thanks for response. The main reason I'm looking for a second language
is to better design the API so that it's generic enough to support
other languages. Considering the second language while designing the
API helps to see what should be generic and what do not need to be.
Jelly? No.. :-) (We're trying to make things easier.)
--
Ersin
On 12/10/05, Emmanuel Lecharny <el...@gmail.com> wrote:
> Hi Ersin,
>
> from my point of view, choose whatever langage that fit your needs. As
> the way you are going to interface this langage to Apache Directory
> Server is somehow generic, we will perfectly be able to implement a
> second langage if needed.
>
> Of course, if you were to chose Jelly, I will veto it ;)
>
> You could also investigate something like Janino
> (http://www.janino.net/index.html#what) which is used internally by
> groovy.
>
>
>
> On Sat, 2005-12-10 at 14:22 +0200, Ersin Er wrote:
> > Hi all,
> >
> > We're working on adding DIT based stored procedure support to
> > ApacheDS. I'll give more details in the next days and I'll get your
> > ideas but now I request help about choosing a scripting language that
> > we can support. Our main focus is on supporting Java Byte Code and we
> > also want to design the API to allow adding new language
> > implementations. To achieve such a design we decided to implement one
> > more language which is possibly a scripting language.
> >
> > We may consider Mozilla Rhino, Groovy, Jython or whatever else.. The
> > important point for our selection is that the language should be an
> > appropriate one for JNDI operations and it should also be as much as
> > close to Java type system.
> >
> > Cheers,
> > --
> > Ersin
>
>
--
Ersin
Re: [ApacheDS][SP] Stored Procedure Languages
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi Ersin,
from my point of view, choose whatever langage that fit your needs. As
the way you are going to interface this langage to Apache Directory
Server is somehow generic, we will perfectly be able to implement a
second langage if needed.
Of course, if you were to chose Jelly, I will veto it ;)
You could also investigate something like Janino
(http://www.janino.net/index.html#what) which is used internally by
groovy.
On Sat, 2005-12-10 at 14:22 +0200, Ersin Er wrote:
> Hi all,
>
> We're working on adding DIT based stored procedure support to
> ApacheDS. I'll give more details in the next days and I'll get your
> ideas but now I request help about choosing a scripting language that
> we can support. Our main focus is on supporting Java Byte Code and we
> also want to design the API to allow adding new language
> implementations. To achieve such a design we decided to implement one
> more language which is possibly a scripting language.
>
> We may consider Mozilla Rhino, Groovy, Jython or whatever else.. The
> important point for our selection is that the language should be an
> appropriate one for JNDI operations and it should also be as much as
> close to Java type system.
>
> Cheers,
> --
> Ersin