There is another possibility. You could, in principle, create an OO VRML
filter which could handle the OO extensions. This filter would interpret
the VRML data stream and then pass it on (possibly modified) to a standard
VRML browser. It would maintain its own copy of the scene graph for
answering queries concerning field names. The EventInObserver is more
complicated, but I believe it could be handled by adding routes and nodes
to the scene to intercept all events and pass them to the filter, which
would then call the appropriate EventInObserver. It would be a lot of work
obviously, and not very efficient (with a lot of duplication between the
filter and the browser), but would have the advantage of working with
standard VRML browsers.
There are a number of ways to actually implement such a filter. One way
would be through Java Beans. SGI announced Java Bean support for Cosmo,
though I don't think they said exactly when. I suspect many or most of the
other VRML browser vendors will follow eventually. So if you implemented a
filter such as I described as a bean container, you would have a fairly
standard, cross-platform design rather than be dependent on a proprietary
API. On the other hand, Liquid Reality exists right now, which is a very
big advantage over the bean version of Cosmo, which does not.
Michael St. Hippolyte
mash@trapezium.com