Re: [openvrml-develop] Status update: modularization

[Josip A. <jo...@vr...>]

Braden McDaniel wrote:
> At this point I have successfully ported the JavaScript scripting 
> backend to a dynamically loaded module; it seems to be working just 
> fine. I would like to take this opportunity to fix the long-ailing Java 
> scripting engine. I'm just now getting an idea of what I'm in for.
> 
> It hasn't been compiling for a while; but that's not the worst of the 
> problems. It is currently written assuming that all Java scripts in a 
> world would share the same VM. I don't think that's desirable; and I'm 
> even less sure that it's workable: it's my understanding that each 
> vrml.node.Script subclass will need to have its base URI added to the 
> classpath; and surely different Scripts need to run in isolation from 
> one another.

Oh I'm not that sure about that classpath thing. IIRC from the spec, 
each script needs to have access to full usual java stuff. Like, 
standard J2SE API.
The catch is, other components, 'optional' packages may be available 
too. Like, JMF, J3D, JavaComm etc. We usually enable them by placing 
them into jre/lib/ext or adding to runtime by java -Djava.ext.dirs=...
So that's why I call them 'usual' - whatever this specific JVM has 
installed.
And you can use that to your advantage - just exec jvm with 
-Djava.ext.dirs=scripts dir(s). IIRC it has to be defined during JVM 
bootstrap.
As for isolating scripts from one another, I think this could be handled 
by java security manager/policy. Like, you can forbid reflection so an 
object can't inspect others.

> So, proceeding with the assumption that we need a VM-per-Script node, 
> the JNI documentation says that you can have no more than one VM per 
> thread. That means that the openvrml::script subclass in the Java script 
>   engine needs to spawn its own thread and function more-or-less as an 
> active object. This is nontrivial code, none of which is in place.

I say drop VM-per-Script idea.
One interpreter to host scripts, that's ok.
I'll gladly help you with that, in fact I think we can use VRSpaceLoader 
for starters. That's what it does, loads classes in runtime...
As for thread-per-script model... sure, it has to be done that way.
So, say, you spawn a jvm and send/receive events thru a pipe or...?
Suppose you send events like 'script <id> <eventname> <eventvalue>'.
There's more vrspace code to handle it, but it's around already.
And yes it's not trivial...;)

Regards...