Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Sean McGrath hits a home run
 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
