[webkit-help] Exporting WebCore API

[Thomas Palmer]

Anyway, thanks again for the quick response last time. I've considered that
I'll probably look for other options.

- Tom


On Sat, Aug 11, 2012 at 10:23 PM, Thomas Palmer <tjpalmer at tjpalmer.com>wrote:

> Thanks for the info. I had seen the goals page, but it's hard to know for
> sure what's potentially in scope. DOM can be for more languages than JS,
> but I'm okay with what the maintainers consider appropriate.
>
> I guess I'll look at source control history, see if I can take the churn
> level, and find out what I can do on my own.
>
> One other thing. Is there a chance of being willing to simplify the
> include dirs list by always consistently including from a few top-level
> dirs? I might be willing to go to the pain myself of changing all the
> include directives, but only if I knew y'all would consider accepting it
> when I was done.
>
> Thanks,
> Tom
>
>
> On Sat, Aug 11, 2012 at 7:00 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>
>> On Sat, Aug 11, 2012 at 4:49 PM, Thomas Palmer <tjpalmer at tjpalmer.com>wrote:
>>>
>>> This has probably been asked before, although I haven't used the right
>>> search terms.
>>>
>>> I would __LOVE__ to use WebCore as a C++ library, and it has all these
>>> wonderful things like WebGLRenderingContext and dom things and whatnot. I'd
>>> have little need to use another UI toolkit in my life, so far as I'd be
>>> concerned. But none of it is exported in the public WebKit interface, nor
>>> is it available, for example, in the webkitgtk so file.
>>>
>>> I have seen the partial Chromium interface (having tried it first
>>> through Chromium itself), and I see that WebKit2 is exposing a bit at least
>>> in a C interface. Also, apparently the internal WebCore APIs are considered
>>> unstable. Is all this correct?
>>>
>>> What is the game plan for the future on this front?
>>>
>>
>> http://www.webkit.org/projects/goals.html
>> WebKit is not a bundle of maximally general and reusable code.
>> We build some general-purpose parts, but only to the degree needed to be
>> a good web content engine.
>>
>> So if your plan is to re-use our code for other purposes, we're unlikely
>> to accommodate that.
>>
>> If I went to the effort of trying putting exports on all the WebCore APIs
>>> using a #define that is turned off by default, could that possibly be an
>>> acceptable patch? How unstable is WebCore? I'm inclined to think I'd be
>>> willing to ride with the flow if it's at least semi-stable, and I suspect
>>> WebKit maintainers also feel little need to churn too much.
>>>
>>
>> What are you referring to by WebCore APIs? We refactor and change class
>> names, methods, etc... in WebCore all the time. WebKit API is there
>> explicitly for this purpose so that we don't have to be constrained by
>> external projects.
>>
>> - Ryosuke
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-help/attachments/20120813/cfd89a8e/attachment.html>