[webkit-dev] Accessing WebKit JS binding classes from non-WebKit JavaScript Core applications?
Hi, I'm working on a project which makes use of JavaScriptCore as a scripting engine outside of WebKit. It would be very helpful to us if we could get access to the DOMParser and XMLSerializer classes which are in WebKit's DerivedSources area. However, it seems that those libraries are using JavaScript Core's internal/private API (JSC::ExecState, JSC::Value, etc.) rather than the public interface expected by external users of JavaScript Core. We'd also like to avoid pulling in the internal WebKit headers anyway, as this would complicate our build system (for example, we'd like to be able to do this just using the header files provided by Ubuntu's libwebkit-dev package). I'm fine with writing forward-declaration classes and stub methods for the purpose of letting the C++ linker figure it all out, but JSC::JSValue seems to get in the way of this idea, since the getConstructor() methods on the libraries we want return it by value rather than by reference (and it doesn't appear to be a simple reinterpret_cast like it is for the other public-API classes). Is there some official way that we can get at WebKit's DerivedSources library functionality in a non-WebKit JavaScript Core application, or can anyone think of some tricky-but-relatively-clean way to do it that doesn't involve our app having to see JSC's internal API? Thanks in advance. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Accessing WebKit JS binding classes from non-WebKit JavaScript Core applications?
DerivedSources are generated from here: http://trac.webkit.org/browser/trunk/WebCore/DerivedSources.make I think what your'e thinking of as DerivedSources is actually just the javascript bindings, which will be useless to you w/o the actual implementations in WebCore. If for some reason you wanted to write your own custom bindings which use JSC's public API instead of the internal one which WebCore uses, you could make your own generator script: http://trac.webkit.org/browser/trunk/WebCore/bindings/scripts/ You can see examples of those scripts being run in DerivedSources.make or in run-bindings-tests: http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/run-bindings-tests In short, this is not a supported configuration. :) I'm also not really sure it's on topic for this list. Best of luck! -eric On Tue, Apr 27, 2010 at 3:44 PM, Josh Shagam joshua.sha...@am.sony.com wrote: Hi, I'm working on a project which makes use of JavaScriptCore as a scripting engine outside of WebKit. It would be very helpful to us if we could get access to the DOMParser and XMLSerializer classes which are in WebKit's DerivedSources area. However, it seems that those libraries are using JavaScript Core's internal/private API (JSC::ExecState, JSC::Value, etc.) rather than the public interface expected by external users of JavaScript Core. We'd also like to avoid pulling in the internal WebKit headers anyway, as this would complicate our build system (for example, we'd like to be able to do this just using the header files provided by Ubuntu's libwebkit-dev package). I'm fine with writing forward-declaration classes and stub methods for the purpose of letting the C++ linker figure it all out, but JSC::JSValue seems to get in the way of this idea, since the getConstructor() methods on the libraries we want return it by value rather than by reference (and it doesn't appear to be a simple reinterpret_cast like it is for the other public-API classes). Is there some official way that we can get at WebKit's DerivedSources library functionality in a non-WebKit JavaScript Core application, or can anyone think of some tricky-but-relatively-clean way to do it that doesn't involve our app having to see JSC's internal API? Thanks in advance. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Accessing WebKit JS binding classes from non-WebKit JavaScript Core applications?
Thanks. I apologize for mincing terminology - I'm not particularly versed in how WebKit is put together, where WebKit ends and JavaScriptCore begins, etc., and I've mostly been banging my head against this based on looking at work that some of my coworkers have done. :) I should be more specific that we are in fact linking against WebKit and so we will have the implementations available. We are actually using full WebKit for another part of the system as well, but we'd like to be able to access WebKit's JS bindings from outside of the WebKit view. It looks like bindings/scripts bit will help me get on the right track, in any case. Thanks for the pointer. Eric Seidel wrote: DerivedSources are generated from here: http://trac.webkit.org/browser/trunk/WebCore/DerivedSources.make I think what your'e thinking of as DerivedSources is actually just the javascript bindings, which will be useless to you w/o the actual implementations in WebCore. If for some reason you wanted to write your own custom bindings which use JSC's public API instead of the internal one which WebCore uses, you could make your own generator script: http://trac.webkit.org/browser/trunk/WebCore/bindings/scripts/ You can see examples of those scripts being run in DerivedSources.make or in run-bindings-tests: http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/run-bindings-tests In short, this is not a supported configuration. :) I'm also not really sure it's on topic for this list. Best of luck! -eric On Tue, Apr 27, 2010 at 3:44 PM, Josh Shagam joshua.sha...@am.sony.com wrote: Hi, I'm working on a project which makes use of JavaScriptCore as a scripting engine outside of WebKit. It would be very helpful to us if we could get access to the DOMParser and XMLSerializer classes which are in WebKit's DerivedSources area. However, it seems that those libraries are using JavaScript Core's internal/private API (JSC::ExecState, JSC::Value, etc.) rather than the public interface expected by external users of JavaScript Core. We'd also like to avoid pulling in the internal WebKit headers anyway, as this would complicate our build system (for example, we'd like to be able to do this just using the header files provided by Ubuntu's libwebkit-dev package). I'm fine with writing forward-declaration classes and stub methods for the purpose of letting the C++ linker figure it all out, but JSC::JSValue seems to get in the way of this idea, since the getConstructor() methods on the libraries we want return it by value rather than by reference (and it doesn't appear to be a simple reinterpret_cast like it is for the other public-API classes). Is there some official way that we can get at WebKit's DerivedSources library functionality in a non-WebKit JavaScript Core application, or can anyone think of some tricky-but-relatively-clean way to do it that doesn't involve our app having to see JSC's internal API? Thanks in advance. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Accessing WebKit JS binding classes from non-WebKit JavaScript Core applications?
Various WebKit ports expose different bindings. The JS bindings are only exposed to scripts on pages run inside WebKit. If you have your own separate javascript environment, you would need to set up your own custom bindings for that environment. We don't really provide clean APIs for that, however, there has been talk over the years of taking the bindings/scripts and making it possible for clients of WebKit to generate JSC-API compatible autogenerated bindings wrapping their own implementation objects. You'd still have to write your own implementation objects which talked to the right pieces of WebKit/WebCore however. I think you'll run into a world of pain if you try and just expose guts of WebCore to clients outside of WebCore w/o having gone through the normal WebCore parsing mechanisms and created a Page, Frame, Client objects, etc. Anyway, best of luck and we look forward to seeing your contributions. -eric On Tue, Apr 27, 2010 at 3:56 PM, Josh Shagam joshua.sha...@am.sony.com wrote: Thanks. I apologize for mincing terminology - I'm not particularly versed in how WebKit is put together, where WebKit ends and JavaScriptCore begins, etc., and I've mostly been banging my head against this based on looking at work that some of my coworkers have done. :) I should be more specific that we are in fact linking against WebKit and so we will have the implementations available. We are actually using full WebKit for another part of the system as well, but we'd like to be able to access WebKit's JS bindings from outside of the WebKit view. It looks like bindings/scripts bit will help me get on the right track, in any case. Thanks for the pointer. Eric Seidel wrote: DerivedSources are generated from here: http://trac.webkit.org/browser/trunk/WebCore/DerivedSources.make I think what your'e thinking of as DerivedSources is actually just the javascript bindings, which will be useless to you w/o the actual implementations in WebCore. If for some reason you wanted to write your own custom bindings which use JSC's public API instead of the internal one which WebCore uses, you could make your own generator script: http://trac.webkit.org/browser/trunk/WebCore/bindings/scripts/ You can see examples of those scripts being run in DerivedSources.make or in run-bindings-tests: http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/run-bindings-tests In short, this is not a supported configuration. :) I'm also not really sure it's on topic for this list. Best of luck! -eric On Tue, Apr 27, 2010 at 3:44 PM, Josh Shagam joshua.sha...@am.sony.com wrote: Hi, I'm working on a project which makes use of JavaScriptCore as a scripting engine outside of WebKit. It would be very helpful to us if we could get access to the DOMParser and XMLSerializer classes which are in WebKit's DerivedSources area. However, it seems that those libraries are using JavaScript Core's internal/private API (JSC::ExecState, JSC::Value, etc.) rather than the public interface expected by external users of JavaScript Core. We'd also like to avoid pulling in the internal WebKit headers anyway, as this would complicate our build system (for example, we'd like to be able to do this just using the header files provided by Ubuntu's libwebkit-dev package). I'm fine with writing forward-declaration classes and stub methods for the purpose of letting the C++ linker figure it all out, but JSC::JSValue seems to get in the way of this idea, since the getConstructor() methods on the libraries we want return it by value rather than by reference (and it doesn't appear to be a simple reinterpret_cast like it is for the other public-API classes). Is there some official way that we can get at WebKit's DerivedSources library functionality in a non-WebKit JavaScript Core application, or can anyone think of some tricky-but-relatively-clean way to do it that doesn't involve our app having to see JSC's internal API? Thanks in advance. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Accessing WebKit JS binding classes from non-WebKit JavaScript Core applications?
Okay, that's what I was afraid of. For now I think I'll just write bindings against libxml, then. Thanks. Eric Seidel wrote: Various WebKit ports expose different bindings. The JS bindings are only exposed to scripts on pages run inside WebKit. If you have your own separate javascript environment, you would need to set up your own custom bindings for that environment. We don't really provide clean APIs for that, however, there has been talk over the years of taking the bindings/scripts and making it possible for clients of WebKit to generate JSC-API compatible autogenerated bindings wrapping their own implementation objects. You'd still have to write your own implementation objects which talked to the right pieces of WebKit/WebCore however. I think you'll run into a world of pain if you try and just expose guts of WebCore to clients outside of WebCore w/o having gone through the normal WebCore parsing mechanisms and created a Page, Frame, Client objects, etc. Anyway, best of luck and we look forward to seeing your contributions. -eric On Tue, Apr 27, 2010 at 3:56 PM, Josh Shagam joshua.sha...@am.sony.com wrote: Thanks. I apologize for mincing terminology - I'm not particularly versed in how WebKit is put together, where WebKit ends and JavaScriptCore begins, etc., and I've mostly been banging my head against this based on looking at work that some of my coworkers have done. :) I should be more specific that we are in fact linking against WebKit and so we will have the implementations available. We are actually using full WebKit for another part of the system as well, but we'd like to be able to access WebKit's JS bindings from outside of the WebKit view. It looks like bindings/scripts bit will help me get on the right track, in any case. Thanks for the pointer. Eric Seidel wrote: DerivedSources are generated from here: http://trac.webkit.org/browser/trunk/WebCore/DerivedSources.make I think what your'e thinking of as DerivedSources is actually just the javascript bindings, which will be useless to you w/o the actual implementations in WebCore. If for some reason you wanted to write your own custom bindings which use JSC's public API instead of the internal one which WebCore uses, you could make your own generator script: http://trac.webkit.org/browser/trunk/WebCore/bindings/scripts/ You can see examples of those scripts being run in DerivedSources.make or in run-bindings-tests: http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/run-bindings-tests In short, this is not a supported configuration. :) I'm also not really sure it's on topic for this list. Best of luck! -eric On Tue, Apr 27, 2010 at 3:44 PM, Josh Shagam joshua.sha...@am.sony.com wrote: Hi, I'm working on a project which makes use of JavaScriptCore as a scripting engine outside of WebKit. It would be very helpful to us if we could get access to the DOMParser and XMLSerializer classes which are in WebKit's DerivedSources area. However, it seems that those libraries are using JavaScript Core's internal/private API (JSC::ExecState, JSC::Value, etc.) rather than the public interface expected by external users of JavaScript Core. We'd also like to avoid pulling in the internal WebKit headers anyway, as this would complicate our build system (for example, we'd like to be able to do this just using the header files provided by Ubuntu's libwebkit-dev package). I'm fine with writing forward-declaration classes and stub methods for the purpose of letting the C++ linker figure it all out, but JSC::JSValue seems to get in the way of this idea, since the getConstructor() methods on the libraries we want return it by value rather than by reference (and it doesn't appear to be a simple reinterpret_cast like it is for the other public-API classes). Is there some official way that we can get at WebKit's DerivedSources library functionality in a non-WebKit JavaScript Core application, or can anyone think of some tricky-but-relatively-clean way to do it that doesn't involve our app having to see JSC's internal API? Thanks in advance. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
