On Nov 24, 2007, at 8:10 PM, Alp Toker wrote:
We've started re-modelling the WebKit/GTK+ public API on the WebKit
Objective-C API, since it's closer to GTK+ conventions than our
existing API (eg. WebView vs Page).
Going through the headers and documentation, I sometimes notice
concepts that don't quite match up with the state of WebCore or
appear redundant.
Any specifics?
I'm wondering what the developers and users of the current API would
do differently if they could re-write it today without any
consideration for backward compatibility.
What would you change? What's obsolete? Any poorly named methods?
If we had the chance to do it over again:
- I would remove WebDocumentView and subclasses,
WebDocumentRepresentation and subclasses, and WebFrameView from the
public API, and just put the relevant methods on WebFrame with the
option to test for certain capabilities that may only be present
conditionally (such as ability to convert to string). This is what was
done in the COM API. This is probably the biggest needless complication.
- I probably wouldn't expose WebArchive and WebResource in quite the
same way.
- It's also possible the design the API to not have WebFrame be a
heavyweight object, but just an identifying token, with all the real
API on WebView. However WebView already has a huge number of methods,
so it's probably sufficient to give good convenience wrappers for
common operations at the WebView level.
- I wouldn't directly expose objects relating to specific network APIs
since this makes things hard to change later.
That's the main things I can think of. I bet Darin has more.
You didn't ask, but some things I like include:
- The main object you interact with being a view
- ObjC DOM API that reflects the DOM specs, something special-purpose
and handwritten would be harder to maintain
- The sets of delegate methods provided (corresponding to signals in
other ports probably).
What parts do application developers have the greatest difficulties
with?
I don't think there is that much API confusion. The bits I have seen
are mostly about interfacing to stuff inside the engine, like the way
to talk to scripting.
Would you have included more default behaviour, forced application
developers to implement more policy, or is the balance just right?
I think the Mac port does a pretty good job of striking the right
balance. The only problem is that the default behaviors we chose are
designed to make sense in a browser, and you have to do work to
override them for less browsery uses like a mail or IRC client. Not
sure how to fix this, though.
This information should help the GTK+ port and others avoid making
the same mistakes.
I bet Darin has more thoughts on this topic.
Cheers,
Maciej
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
