I’ve been doing some work with extensible protocol envelopes recently,
with a very strong emphasis on size, processing efficiency, extensibility,
and evolvability. On a lark, since I’ve been
thinking
about it for a few years, I thought I’d try to toss in the use of RDF, just to
see how far I could go with it. As it turns out, pretty far.
I’d like to be able to talk more about this now, but can’t; it’ll have to
wait, because I’m being paid to do it by somebody with competitors 8-). But I
can certainly pass along one rather enlightening observation that I made …
Protocols typically work with a predicate(aka header)/value tuple.
If you’ve ever worked with triples though, you quickly realize the problem with
a double; it’s not everything you need to know. In this case, you don’t know the
subject; what
has a media type, what is of length 342 bytes, what is identified
by this URI? Most protocols, therefore, define their subjects not in the message,
but in the specification. For example,
here are some
possible subjects of an HTTP message.
This is fine when you’re predefining headers in a spec; there’s still a
self-descriptive path from bits-on-the-wire to what-is-the-subject-of-this-header.
But for extension headers, it doesn’t cut it; you’ve got a predicate (the header
name) and an object (the header value), but no subject.
It would help to have RDF available to us when defining protocol extensions.
On the brand-spankin-new REST IRC channel
(does anybody have the ability to set up a
chump and/or
log bot?),
Joe Gregorio asks;
[18-Feb:17:02 jcgregorio] ok, quick question about DELETE, does success mean the URI *has* to then go 404 or 410?
[18-Feb:17:02 jcgregorio] here is the context
[18-Feb:17:02 jcgregorio] I am adding support for the AtomAPI to a wiki
[18-Feb:17:02 jcgregorio] one of the actions is to DELETE a definition
[18-Feb:17:03 jcgregorio] but as far as a wiki is concerned, *all* words exist, they just don't have definitions yet
[18-Feb:17:04 jcgregorio] for example: http://www.intertwingly.net/wiki/pie/ALongWikiWordWhichHasNeverBeenEdited
[18-Feb:17:05 jcgregorio] my implementation now gives a 200 on DELETE, which removes the definition, but doin a GET on the DELETED URI returns a valid Atom Entry with empyt content
Great question. I’d say that it’s up to the server to interpret what DELETE
means (within the bounds of the RFC 2616 definition, of course). The behaviour
you describe for the Wiki there is reasonable, I’d say.
A flurry of systems aching to be engulfed by the Web this week;
Welcome aboard!
I started tracking another Web services metric last night;
the number of WS-I members. I’m not
expecting this to bare any fruit (i.e. show the expected decline) anytime soon, as that will
certainly lag the non-deployment of
Web services on the Internet
by at least a couple of years. But it’ll be interesting to watch when it starts moving.
AFAIK, they don’t have an “affiliate” program yet, which is something the
more mature organizations will use to boost membership for a number of
reasons (including waning interest in the space). That will
certainly impact this metric if and when it happens.
Oh my,
WS-Discovery
is a Web service spec I might actually use! Horror! 8-)
When I heard what it was, and that it was written by BEA, I was
sure that Yaron Goland would be
involved, after all his
related work
on
UPnP.
He wasn’t, nor was he even acknowledged. Odd.
But there’s not really too much to say about it (at least until I do
a detailed review). Link local
discovery is a pretty well understood domain, and the authors of this
spec seem to grok it at least as well as I do. The use of SOAP/XML
is unfortunate, I’d say, because of its bloat; you really need to keep
things lean for multicast discovery so as to fit everything in a single
datagram. Some kind of binary-encoded SOAP would be useful here.
I sort of wonder why
Rendezvous or
LLMNR
weren’t adopted; the former
has a whole lot of support and running code behind it, while the latter
has MS and should be published as an RFC shortly. But I suppose that
nothing’s really close to critical mass in this space, so I can’t blame them
for starting from scratch.
There’s also mention of a “SOAP/UDP” spec, which is “To be published”.
That’ll be interesting to see, especially if there’s a compact (but still
extensible) binary encoding. What’s suggested in the spec, re “UNICAST_UDP_REPEAT”
and “APP_MAX_DELAY”, and comments such as “waiting for timers” suggests
that it might be more a case of trying to reinvent parts of TCP rather than
embracing the message-per-datagram model which seems to work so well. But my
experience there is rather limited, so I’d be happy to be proven wrong.