Hey Adam,
A few clarifications...
On Apr 8, 2010, at 6:23 PM, Adam Treat wrote:
Can someone please point to the bug report and the forum where this
development was discussed by the greater WebKit community?
We picked the name "WebKit2" in the hopes of picking something really
bland. Apparently that backfired, because it seems to make this
project seem like a bigger deal than it is. Basically, you can think
of this as a new port-specific API. But we're trying to put some
general mechanisms in this API, so other ports can use it if they
choose. We are also welcoming input from the whole WebKit community on
the design, architecture and direction of this work. It is at a very
early stage, barely enough that you can build a trivial demo browser
on top of it. We decided that our proof of concept was far enough
along at that point that we should make the code public for community
review and input.
Nothing about the way existing ports work will go away, either
immediately or in the foreseeable future. There will not even be any
extra maintenance burden for anyone. WebCore will remain much as it
is, there is imply a new WebKit layer on top now available. In fact,
Apple's port for Mac OS X will continue to be maintained and will
still be available as a system API.
I hope this addresses some of your concerns.
Regards,
Maciej
Cheers,
Adam
On Thursday 08 April 2010 08:58:22 pm Maciej Stachowiak wrote:
On Apr 8, 2010, at 5:47 PM, Xan Lopez wrote:
I suppose I could wait until you land the patches and see by myself,
but:
- In the wiki you mention that one goal of the new framework is to
provide a stable C-based API. Is this meant as a public API for
WebKit, the same in all platforms (like JSC), or a stable internal
API
for embedders to use in order to implement their native APIs on top?
From some lines in the wiki (like WKView wrapping native objects)
it
seems like you want to do the former, but that seems like quite a
massive effort and the loss of an important selling port of the
various WebKit ports.
It will be available as a public API, but as Darin explained, it's up
to individual ports whether to wrap this API, expose it directly, or
do some combination. For the Mac OS X API, we will be doing a
combination.
- Does your new framework require any significant changes in
WebCore?
Could you briefly summarize them?
No WebCore changes are required - it works with the existing WebCore.
- Do you see valid usecases in the long term for the "traditional"
ports or are your plans to quickly transition all code to the new
system as soon as it's ready?
I think that would be up to the individual ports. We expect that on
Mac OS X, we will have to support the "classic" WebKit API for a long
time, perhaps indefinitely, in parallel with the new WebKit2-based
API.
Regards,
Maciej
_______________________________________________
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
