The problem with the generic script container which is using BSF is that its quite limited as to what it can do with introspection. For example, I'm don't think it can get at the attr_writer variables in Ruby so it can't support Ruby introspection the way the C++ Ruby container does, and there's probably similar problems with other languages. I also couldn't see how to get it to work with scopes properly without using a new BSFManager for each instance which means recompiling the script for each instance which is a bit inefficient. So at least for now I think it is useful to keep the langauge specific containers (i've just added a rhino one to the sandbox).
What i'd like to do now is just implement a few containers and get support for all the things like scopes, lifecycle, async, properties and references working so we can clearly see what code can be made common. If you'd like to do Ruby or add support for something like async or component lifecylces that would be great. ...ant On 9/13/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
Hi Ant, Sequel to our last chat over IRC I took a look at your Sandbox. I am able to understand all of what you have done there. A couple of thoughts / questions ... - So would it be that we just have this one 'ScriptContainer' that will take care of javascript, ruby, groovy. - Would it be good to have a Script Registry (like the wsdl registry and so on) that would have compiled scripts. So given a script source one can get a BSFEngine from the registry. But then what about the context info (properties and references) - how do we set them in a 'flyweight' way? - What do we do about introspectable component type info? Should we have an interface for which we will have implementations for various script types? Please let me know your thoughts on the next steps with the Sandbox stuff and what I can help you out with? Thanks - Venkat
