Subj : Re: Embedding spidermonkey in a C++ application To : netscape.public.mozilla.xpcom,netscape.public.mozilla.jseng From : John Bandhauer Date : Mon Sep 05 2005 04:25 pm Thomas Sondergaard wrote: > I've embedded spidermonkey in C++ application using the jsapi, and while > it works it is a lot of work to write and maintain wrappers and error > prone too. Phil McLachlan (quoted below) has posted questions here about > using XPCOM, which I think sound like an interesting option, except it > is not clear to me whether XPConnect is deprecated and should not be used? XPConnect is certainly not deprecated. IMO it is still the best way to bridge between Spidermonkey and C++ code. Don't be confused by others' suggestions about how mozilla plugins ought to be implemented using npapi rather than the old 'new' xpcom plugin api. It sounds like you are not talking about implementing mozilla plugins. > > I'd like you seasoned spidermonkeys to help me answer this simple question. > > In a C++ application I wish to make a document scriptable. It is not > exactly a HTML DOM-document, but something similar, ie. it is a > tree-like structured document with typed nodes that have attributes. The > document is implemented as a set of C++ classes, which will need to be > exposed to the script. What would you recommend > > * Using XPCOM/XPConnect > * Write the wrappers by hand using js-api > * Something else, ie roll-your-own swig-like wrapper generator > Certainly XPConnect. The mozilla/dom code is quite daunting. But, I'm sure you don't need to support anything as complicated. John. > Best regards, > > Thomas Sondergaard > > Phil McLachlan wrote: > >> "Phil McLachlan" wrote in message >> news:dd8m5o$ok62@ripley.netscape.com... >> >>> We are investigating using XPCOM as a framework for our project. Our >>> application will run as a stand-alone executable, and it will be used >>> as a plug-in within browsers: Mozilla, Safari, and IE. We require JS >>> scripting of our application, so packaging Spidermonkey with our >>> application seems appealing. In this case, we could use XPConnect to >>> perform the integration. >>> >>> I've noticed that XPCOM's plug-in API (XPConnect?) has been replaced >>> by npruntime. Is this because plug-in writers are moving towards >>> using ActiveX integration in IE with npruntime wrappers for the other >>> browsers? I reckon this would eliminate having to package a JS engine >>> with a plug-in, which is currently the approach used by Macromedia >>> Flash and Adobe Acrobat Reader. On the other hand, writing the >>> npruntime wrappers could become labour intensive. Is there a >>> npruntime to ActiveX bridge? What is the recommended approach for >>> developing rich environment browser plug-ins? It would be nice, if >>> we could also use a JS engine with our stand-alone executable. >> >> >> >> I guess using XPCOM, XPConnect, and embedded Spidermonkey is a better >> option for us, because it allows us to reuse the JS in our stand-alone >> executable. However, XPConnect being depricated in favour of >> npruntime scares me a bit. Is anyone using npruntime to script their >> application with embedded Spidermonkey, or is that not the intent? >> >> >>> Also, in this context, which is better to use: standalone XPCOM or >>> XPCOM with the entire Mozilla source tree? If possible, I imagine >>> the standalone implementation would be more desirable. Is XPCOM >>> packaged as a separate product that you can get frozen stable >>> interfaces and implementations for? Is there documentation for the >>> various Mozilla XPCOM libraries? I read the standalone is not >>> compatible with the one in the Mozilla tree. Why is this, and should >>> this be a concern? >>> >>> Assuming standalone XPCOM is the way to go, can someone point me to >>> directions on how to download it and use it with XPConnect/Spidermonkey? >> >> >> >> Okay, I've found the Gecko SDK, which comes compiled and packaged for >> the various Mozilla releases. This seems to work well, as opposed to >> standalone XPCOM, which seems to have become broken in the Mozilla >> build in the past due to neglect. >> >> >>> Thanks for any advice. >> >> >> >> .