[webkit-dev] Objective-C API: What would you change?

[Maciej Stachowiak]

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