[
Lists Home |
Date Index |
Thread Index
]
Tim Bray wrote,
> http://www.itworld.com/nl/xml_prac/04182002/
>
> Outstanding. -Tim
Worth reading for this alone,
Firstly, APIs are no substitute for actually understanding what is
going on in any system. In some cases - such as complex calculations
and the like - I can see why APIs are vital. But for things like HTTP
- protocols - I have my doubts. The APIs get in the way of
understanding the concepts, which are really quite simple. When the
API hits the wall - as happened in my case - your productivity hits
the wall too, unless you can think past the API to the underlying
reality.
But I think Sean's trying to wring more out of this observation than it
really warrants. The HTTP APIs he has to hand are unhelpful (something
I find all too easy to believe) so he did the sane thing and 'created a
socket and started to send and receive stuff "by hand," as it were'.
But what's a socket? Now that BSD derived stacks are ubiquitious it's
all too easy to forget that the Berkeley Socket API is just that: an
API. It's just one of several programmatic interfaces to a TCP/IP
stack. If you look at the subtitle of Steven's "Unix Network
Programming" vol. 1, you see it reads "Networking APIs: Sockets and
XTI". Most people probably don't read the 120 odd pages on the X/Open
Transport Interface, but they're there all the same.
I think there's a slightly different lesson to learn from Sean's
experience. Partly it's just that a lot of APIs are badly designed ...
in a lot of cases that's because the designers don't really understand
what's going on in the system (having seen the inner workings of rather
too many HTTP client libraries I'm sadly convinced that's all too often
the case).
But some of them aren't, especially ones at lower levels of abstraction.
In the case of the socket API it's so familiar and works so well most
of the time you barely even notice it (for all that it's full of warts
and wrinkles). You couldn't drop down much lower without having to deal
with the TCP/IP state machine in the raw. Being that "close to the
metal" means there are limited degrees of freedom for the API designer,
so comparitively fewer plausible variations ... not so few as to
exclude alternative APIs (viz. XTI), but few enough that the
alternatives are so similar as to be redundant other than to accomodate
differences in host programming languages (eg. the Java Socket API
would be immediately familiar to anyone comfortable with the C-based
Berkeley API).
At higher levels of abstraction there are more degrees of freedom, hence
more alternatives, hence a greater likelihood that an API designers
choice of how to resolve those choices won't be a particularly good
match for some particular application. Either that or the design will
try and leave all options open and produce a clumsy and bloated API
that's unusable in practice.
And this takes us straight back to the datatypes perma-thread. As we
move up the stack from markup there are more degrees of freedom, and we
have the same design options: resolve the choices in one particular way
(read: vendor lock in), or leave them all open (or rather, try but
inevitably fail) and end up with a bloated monstrosity (read: WXS).
I'd be comfortable with an analogy that went something like: SAX is to
XML databinding APIs as the Berkeley Socket API is to HTTP APIs, or as
XML is to WXS. In all cases I'd prefer to stick to the lower level of
abstraction and do the rest by hand.
Cheers,
Miles
|
