OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Sean McGrath hits a home run

[ 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




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS