That's about the way I've been doing it too:
import("libname") // loads in the libname namespace
import("libname", true) // loads in the global namespaceimport() looks for "lib/libname.so" and throws an error if there's a problem loading it. Calls LoadJSFunctions(Handle<Object>), which binds function instances to it. http://www.betterwebber.com/stuff/v8/importex.cc http://www.betterwebber.com/stuff/v8/pluginex.cc That's pretty simplistic, but it's worked so far for what I've been doing (shell with MPI bindings). What OO approach do you have in mind? On Feb 26, 1:45 pm, Stephan Beal <[email protected]> wrote: > On Feb 25, 11:24 pm, Joe Antoon <[email protected]> wrote: > > > But if nobody has done this before, would any of the users be > > interested in supporting a plug-in system like the one I described > > above? There's only a single function that actually needs to be > > embedded in your application to use it, so extensions could be > > developed separate of each other. > > i developed just such a system for the SpiderApe project (http:// > SpiderApe.sf.net), which is a C++ toolkit for expanding SpiderMonkey. > i've recently all but abandoned SpiderMonkey because it's so poorly > documented and certain aspects of it are particularly painful without > good documentation. Since v8 seems to be the only really portable JS > engine out there, i'd like to focus future JS/C++ work on v8. > > That said: if we can come to an agreement on what a plugin model might > need to look like, i could commit some time on this. i have previous > work off of which i could base it, assuming the proposed model is > either close to that code or people are willing to accept whatever i > code ;). > > For SpiderMonkey i wrote ncurses and sqlite3 plugins, and they would > be loaded like this: > > (JS code): > > if( ! dll_load("SQLite3") ) { throw new Error(...); } > var db = sqlite3_open( "path/to/my.db" ); > ... > > By default that would use some compile-time-determined library path to > find a DLL named PluginName.(platform-specific-extension). The DLL > loader was based off of the classloader model described here: > > http://wanderinghorse.net/computing/papers/#classloading_cpp > > and opening the DLL would use a callback mechanism to inject DLL-side > symbols (new JS functions and classes) into the JS context which > opened the DLL. > > The lookup path for plugins could be changed by scripts with something > like: > > dll_classpath_set( dll_classpath_get() + ":/home/me/lib/v8/ > plugins" ); > > (a more OO approach is probably a good idea). The existing code (for > SpiderApe) has been extensively used on Unix platforms, but has also > been shown to run on Windows. Mac - no idea. > > If this basic scenario sounds reasonable as a starting point, i > wouldn't mind trying to throw together a prototype. > > :-? --~--~---------~--~----~------------~-------~--~----~ v8-users mailing list [email protected] http://groups.google.com/group/v8-users -~----------~----~----~----~------~----~------~--~---
