While this subject is up...
Has anyone considered writing the OOPHM client stub as a Java applet
and using netscape.javascript.JSObject to deal with the JS references?
While it wouldn't support direct field references like the current
plugins do, the server-side Jsni class could rewrite those as method
invocations (pass either a get, set or unary operator up to the
server). Java itself could take care of listening for JSObject
destruction: create a weak reference to the JSObject and put that in a
reference queue. The plugin already deals with the Browser GC<->JVM
GC links, so this should "just work" (hah!).
AFAIK, there a is limited amount of magic happening in OOPHM right
now, basically boiling down to
- field getter/setters
- JSObject destruction
- Invocation
The only possible issue I can think of would be hitting that
Window.enableScrolling() bug that killed the previous NPAPI plugin.
On 5-Jun-09, at 9:37 AM, BobV wrote:
>
> An even-crazier setup would be that the locally-installed plugin is
> just a sled for downloading the actual plugin guts from the server.
> This way, a single plugin installation could work with different
> versions of the OOPHM host code.
>
> --
> Bob Vawter
> Google Web Toolkit Team
>
> >
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
