[webkit-dev] Accessing WebKit JS binding classes from non-WebKit JavaScript Core applications?

[Josh Shagam]

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.Shagam at 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.Shagam at 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 at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>>
>>
>>
>>     
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100427/dc3ecde4/attachment.html>