Hmm, what this boils down to. So we currently have two options to decide on: The Jar Service provider mechanism and the servlet init-param listing classes.
In the light of having a real Sling supporting OSGi extension model, I would not make it too easy for microsling to be extensible and implement a separate extension model (Jar Service provider) and hence stick with the init-param method. On the other hand, if we create the microsling-core only containing JavaScript and have a microsling-scripting-ext which contains a bunch of other scripting engines. What would go in the microsling-webapp ? Do we include microsling-scripting-ext or not ? I would say, we include and have a web app with everything but concentrate on the microsling-core project and just have microsling-scripting-ext as a by-product where we can dump scripting engines over time. On the other hand we could create a separate project for each scripting engine (probably outside of microsling inside a sling-scripting container. These would be implemented such as to provide easy use in the real sling. To be used in microsling, the microsling-webapp would have to be manually modified. Ultimately, I still like the init-param based method best for microsling.... Regards Felix Am Mittwoch, den 31.10.2007, 14:50 +0100 schrieb Bertrand Delacretaz: > On 10/31/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > > > ...One simple solution would > > be to have all script engines in microsling but make them optional.... > > ...The detection if the required stuff is available in the classpath could > > be done by just trying to instantiate the engine always. If > > instantiation fails, its not an error, but the engine is not available... > > That might be good enough, but you'd need a list of class names for > potential ScriptEngines, right? > > That list might be an init parameter for the MicroslingMainServlet, so > that people who need other scripting languages just need to add the > corresponding class names to that parameter, and make the engine > classes available. > > We don't need to make scripting engines plugins super-easy in > microsling, I agree that such a mechanism would be sufficient, and > it's very easy to implement and understand. > > -Bertrand
