[
Lists Home |
Date Index |
Thread Index
]
Mike Champion wrote:
> But especially with committee-written standards (and I think this
> reflects the points in Daniel Veillard's post) there may simply be no
> coherent abstraction that can be cleanly encapsulated. I don't know
> enough about HTTP to have an opinion if the APIs are merely bad, or if
> they reflect an unpleasant reality about the conceptual integrity of
> the underlying protocol. (I would tend toward the former). But with
> XML, having spent quite a bit more of my life that I will probably
> care to admit on Judgement Day working on APIs for it, I think it's
> hard to argue that there is a clean abstraction that can be exposed
> with APIs and implementations can be hidden behind.
Maybe the problem isn't with either the APIs or the protocols/formats. I
propose that one must choose: either the API is primary or the
protocol/format is primary. If you decide the API is primary then the
wire format will tend to be pretty ugly and hard to decipher. It will
probably tend to degrade over time because it "doesn't matter much." Try
decoding IIOP ... or, increasingly, SOAP to see this phenomenon in action.
Alternatively you can decide that the wire format is primary and the
programmer abstraction is secondary. Then it will be hard to make a
programmer abstraction that "feels right". The syntactic shortcuts you
use like entities and qnames will become quite inconvenient at the API
level. XML Schema is actually pretty API hostile (like most XML schema
languages) because it allows the description of languages which are nice
to look at, read and type, but have no obvious or natural mapping into
programming language data structures (other than the DOM, which is
inconvenient).
I believe that it is impossible to optimize *both* API and data
representation/protocol. Sean had problems with the APIs becuse the
API's authors did not understand that it was their responsibility to as
closely as possible emulate the capabilities of the wire format. APIs
should abstract over APIs. Wire formats should abstract over wire
formats. But APIs should not abstract over wire formats. They should
offer as close a fidelity as is possible to what is actually going on
underneath.
> Seems like a rehash of Joel Spolsky's Leaky Abstractions article with
> different examples. What did you find outstanding about it?
The thing I think Sean is getting at, (which is different than the thing
Joel Spolsky said) is: "If you are working with something that is
primarily a data format or wire protocol, understand the data format,
not an API abstraction of it. The API will only ever be a poor
reflection of it. If you are working for something that is defined
primarily as an API, understand the API and ignore the data/wire format.
The data/wire format is at best a debugging tool."
As Sean says: "Top amongst my doubts about APIs for things like HTTP is
that HTTP, when all is said and done, is a document exchange protocol."
Paul Prescod
|
