Bertrand, my (user perspective) vote goes to "only (1 engine) in the core, and make all other engines plugins". ESP is fine with me (many people know JS and it's easy enough to learn if they don't). I could also live with no plugin mechanism and just one engine.
I agree with your comment that for starting a sling ecosystem it is beneficial to focus on one language. It makes explaining concepts etc much easier. A slightly off-topic side remark: at a later point it would be great to have application-level plugins that provide certain app infrastructure that is often needed (think web stats, a poll module, etc). These should be easy easy enough to implement for an app developer. It just occurred to me that this *ahem* requirement might influence this discussion. Cheers Michael On 10/31/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > > Hi, > > (ouch - more than five lines once again) > > We have now three script engines in microsling, and some ideas > floating around for more (SLING-90). > > While I find it good to let people experiment with their favorite > scripting language (especially with the "playground" bias of > microsling), I think we need to focus a small number of languages for > our examples, and keep our microsling distribution size slow. I'd keep > only javascript / ESP in the core, and make all other engines plugins. > > Script engines as plugins will be easy to do in Sling OSGi, but we > need some lightweight mechanism for microsling. The same engine jars > should be usable in both microsling and sling. > > My requirements for microsling would be that any script engine jar > file found in the microsling servlet classpath is activated at > startup, including discovery of the file extensions supported by the > engine. > > - o - > > Here are some options, I have not used any of them before so comments > are welcome. > > 1) Use BSF, the Bean Scripting Framework > See http://jakarta.apache.org/bsf/, that's well-known and stable. > > Not sure if and how BSF would help us make script engine plugins. > > 2) Use the JDK 1.6 scripting framework > > > http://java.sun.com/javase/6/docs/technotes/guides/scripting/programmer_guide/index.html > > And that might work for JDK 1.5 as well: > > > http://www.oreillynet.com/onjava/blog/2007/09/scripting_api_for_everyone.html > > 3) Keep our existing interfaces an use the jar service provider mechanism > Jackrabbit uses that for query syntax plugins, a plugin jar needs a > text file like this one: > > > https://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-core/src/main/resources/META-INF/services/org.apache.jackrabbit.core.query.QueryTreeBuilder > > which allows this class to discover the query engines: > > > https://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/query/QueryTreeBuilderRegistry.java > > The spec is here: > > http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service%20Provider > > Surprisingly, it seems like javax.imageio.spi.ServiceRegistry is the > only public JDK class that implements this lookup method. > > - o - > > WDYT, do we agree on keeping just javascript/ESP in the core, yet > support script engine plugins in microsling? > > Which plugin mechanism do you suggest? > > -Bertrand >
