After the discussion about how to make WebKit1 and WebKit2 parallel installable, it seems that no matter how we do it, we will force everybody to at least re-compile. Which in effect is like breaking the ABI.
So, if we are going to break the ABI in the end, I think the best solution for everybody is to bump the binary version to 4.0, that will rename everything, making it parallel installable with any previous version. If anybody knows any other solution that doesn't require to re-compile, please let us know. But we can also take advantage to make small modification to the API, that in most of the cases won't affect the users (because they don't use it, so re-compile would be enough) or the changes would be really minimal. What do you think? Many people haven't migrated to WebKit2 yet, so fortunately we won't break too many applications. Here is my list of possible API changes (without having reviewed the whole API in detail, just a few ideas): - Limit the amount of API we expose to the GObject DOM bindings API. We currently expose every single idl file that is added to the repository, no matter of the API is just a w3c draft, or if it's prefixed, etc. This is giving us a lot of work everytime any idl API changes, and we end up with special cases to deprecate the old API and add new one, for things that have never been used by anybody. So, I propose to only expose "stable" APIs that are unlikely to change. I'm not sure how to define that, though, maybe when the w3c spec is final or whatever. I should also probably not expose anything depending on a feature protected by conditional compilation and not enabled by default in GTK+. I'm open to any proposal in this regard. Of course we would remove all the deprecated API in the DOM bindings for 2.6. - Remove WebKitWebViewGroup. Anders Carlsson told me the other day that WebPageGroup is going to be removed, in favor of sharing settings objects among different web views (like we did before, btw) and moving the user style sheets and user script to a different class (UserContentController). I think most of the WebKit2 users don't use web view groups at all (the default web view group is handled internally and transparently), so we could anticipate to this change and get rid of the WebKitWebViewGroup class. - WEBKIT_VIEW_MODE_SOURCE: The view source mode has been removed from WebCore, so WEBKIT_VIEW_MODE_SOURCE does nothing now and it's marked as deprecated for 2.6. Since WEBKIT_VIEW_MODE_WEB is the only mode, and I don't think there will be more modes, we can probably remove the WebKitViewMode and webkit_web_view_[get|set]_view_mode(). - Probably merge the load-failed and load-failed-with-tls-errors into a single signal (load-failed) and change the default TLS errors policy to FAIL. - Provide more information as parameters of WebKitWebView::create signal, like the target frame, the request, and navigation data. Those could be very useful to implement a proper popup blocker, for example. - Maybe remove form-submitted. This was added with a different idea, and now doesn't look really useful. Feel free to add more ideas here. We will need to discuss every idea individually anyway to see the impact it might have. -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
signature.asc
Description: This is a digitally signed message part
_______________________________________________ webkit-gtk mailing list webkit-gtk@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-gtk