[webkit-gtk] Breaking the API/ABI for 2.6

[Carlos Garcia Campos]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.webkit.org/pipermail/webkit-gtk/attachments/20140603/2755a8ce/attachment.sig>