From: Oliver B. <oli...@jk...> - 2011-03-07 12:38:29
|
Am 07.03.2011 12:13, schrieb Matthias: > Am 07.03.2011, 11:50 Uhr, schrieb Oliver Buchtala<oli...@jk...>: > >> Hi Matthias, >> >> thank you for this information. >> NPAPI plugins are a well supported technique. Moreover, you can create a >> slim application based on qt-webkit. >> >> For me, this approach has one central drawback (if I understand NPAPI >> alright): NPAPI plugins are bound to handle mime-types for the browser. >> It is thus not a general means to provide an API to a JS engine. >> (Correct me if I am wrong) > You can embed npapi plugins with<object> tags in your html page. Based on > the mimetype parameter the corresponding plugin will be loaded. So if you > control the creation of the html page you can just put an<object> tag in > there and you'll always have a plugin running. > Of course if you want to extend the js engine with new functions (let's > say some number crunching) which should be available to any html page this > will not work. Unless you can just pre/postprocess the page before loading > it into the browser and adding a silent<object> tag there. > The good thing about the firebreath is your plugin will work in any > browser with any js engine. I think there's currently no way to do this if > you want to do it without a plugin. > > What's your specific usecase? I want to provide a wrapper to a C++ library > which I want to access from JS. And I always have a plugin running > anyways... > > -Matthias > Hi Matthias, actually there are ways to extend JS engines: V8 and JavascriptCore provide such APIs. Google extends Chrome with some native functionality, same with Webkit and JSC. The only thing is, that these engines are tightly integrated into the corresponding browser environment, and it is not possible to extend them by means of plugins. It would be possible to build chrome or webkit with some extension mechanism that could load and register other extension dynamically. Nevertheless, having to build such monsters is not really pleasing. An alternative: Qt offers a way to make Qt objects available to the underlying JavascriptCore engine (->Webkit). Here I just do not like the fact that one is bound to the use of Qt's objects and cannot use the modules without Qt. My usecase is not concrete, but a general desire. I simply like the idea to develop applications in a hybrid way: graphical interfaces using modern web-development techniques (HTML5, CSS, etc.) and applicational native stuff (e.g., high performance image processing) in C++. My choice for V8 is driven by the facts, that V8 is impressingly fast, it is well documented (in contrast to JSC), and it is simply popular. It's easy to create a V8 instance and add your own extensions. The same is with node.js, which runs a V8 internally, and provides a server side interface to its JS engine. It becomes more and more popular in the javascript community. Not so easy, as stated, it is to get the stuff glued to an existing Web-Widget. Though, there have been efforts (and a running prototype) in the qt-webkit project which binds V8 to webkit. Unfortunately, they are not addressing this task too intensively right now. Having modules for V8, one could use them in a standalone scenario using your own V8 instance. At the same time, without need of extra effort these could be integrated into node.js achieving a web-based solution. An direct integration into a local Web-Widget based application is just an add-on - and seems not to be available tommorrow - but soon for sure. Supposedly, you have a different usecase in mind and a Netscape plugin solution is sufficient. Though, I would be glad to have your opinion :) Bye, Oliver |