Internal Structures
February 28th, 2008
Like Vlad and Roc, I was pretty surprised at the extent of private API use in WebKit. There’s a troll headline on Slashdot right now, and I don’t think any Mozilla developer approves of it.
But, in the slashdot comments, I see claims that David Hyatt’s response somehow addresses the issue at hand. Let me assure you that it does not.
Roc’s post deals with the issue pretty well, but I want to examine a few bits of rhetoric in Hyatt’s comment more closely:
Many of the private methods that WebKit uses are private for a reason. Either they expose internal structures that can’t be depended on, or they are part of something inside a framework that may not be fully formed.
Presumably those private methods also do something useful, and clearly can be depended on if your software is an Apple product. They may not be stable, though.
…we may continue to use the WK method even though it’s not public API just because we need to work on Tiger.
Firefox 3 will be available on Tiger, and those private methods might come in handy. We don’t know that for sure, because we don’t have documentation for any of the private stuff.
I hope Apple will take steps to resolve this bug.
February 28th, 2008 at 10:59 pm
Isn’t this just like MOZILLA_INTERNAL_API?
Ian
February 29th, 2008 at 12:02 am
Ian: haha, but seriously — no.
No, it’s not “just” like any wholly open Mozilla or other FOSS source code, however hidden behind INTERNAL API configuration, because the WK* functions in question are implemented in closed source. Why is that relevant? Because WebKit is open source.
You could say it’s Steve’s house, he doesn’t owe anyone anything, etc. And you’d be right to a certain extent: Mac OS X is, as Nat Friedman points out, a proprietary OS (containing a lot of open source, of course, but augmented and integrated by Apple). If you take this point of view, then who cares about WK* secret APIs? But if you think like this, then you shouldn’t want WebKit to be open source, or care that it is (except for those WK* entanglements).
If you claim to care about open source, then look at the situation with Mozilla. You can use any Mozilla code, violate its abstractions including MOZILLA_INTERNAL_API, fork it nine ways to Sunday. Go nuts. Don’t whine if you make a mess to maintain on your own; do try to get internal APIs externalized where it makes sense — but (unlike the situation with WK* APIs) you don’t have to, you can copy and hack all of the code.
Whatever you do, don’t even try to pass off the sane, advisory boundaries that every software project (indeed, every group of people managing shared territory or resources in the real world) puts around private or friends-and-family areas, with the WK* mandatory dependency on secret, proprietary-OS-specific APIs whose implementations live in binary blob.
It’s all about access, not advice.
/be
February 29th, 2008 at 4:57 am
Note that Apple has the facilities in place to make sure Safari is updated when the OS is.
Seeing that a very common reason for keeping APIs private is so they don’t need to be kept around forever, it could be reasonable for Safari to use them, but to not allow the public to know about it, as they can just update Safari to use the APIs in the new way when they change them.
Anyway, it’s not like Apple gains a lot by having applications run slower on their platform. They don’t have enough applications themselves to enable people to run Mac OS X with Apple software only.
February 29th, 2008 at 1:36 pm
@Brendan,
Really, I meant that almost entirely tongue in cheek. I have in the past been frustrated by it but things have gotten a lot better in 1.9.
Ian