Tim notes
that Googlebot is frequenting his server, and costing him real money.
A quick investigation on an old page
from his log reveals;
HTTP/1.1 200 OK
Date: Wed, 03 Mar 2004 14:20:02 GMT
Server: Apache/1.3.26 (Unix) Debian GNU/Linux
Last-Modified: Wed, 03 Mar 2004 08:00:54 GMT
ETag: "1b404e-f1d-404590b6"
Accept-Ranges: bytes
Content-Length: 3869
Keep-Alive: timeout=15, max=20
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
Like many other agents and caches, Googlebot presumably uses some
“freshness” heuristic based on Last-Modified. As you can see above, Tim’s
server is telling the world that even his archived content changes
frequently. Ergo, Google hits him frequently. Conclusion; don’t do that! 8-)
Full disclosure; my weblog isn’t cacheable at all – not even any
Last-Modified headers – and I have little motivation to fix it because my bandwidth
isn’t metered.
ZapThink gets it
totally backwards;
Rich clients will supplant portals as the primary interface to Web Services and Service-oriented functionality in the enterprise by the end of 2007.
Bzzt.
These guys need to get out more. Go check out some of the
KnowNow or
mod_pubsub
demos for an example of what’s
possible with existing (nevermind
next-generation!!)
thin-clients.
Sure, a fat-client approach may have some minor advantages (more responsive?),
but zero-install is da bomb, baby; once you’ve tried it, there’s no going back. Ask
any CIO; they’ll gladly accept a slightly suckier zero-install solution over a fat
client solution any day of the week.
Phil Wainewright writes;
There is no alternative to messaging. Your only choice is good messaging or bad messaging.
Mostly, sure. But sometimes, when you’ve got very good messaging
beneath, it becomes possible to see new patterns of communication in the
aggregate. Shared memory, for example.
As I was just writing to someone in private email, if you do REST properly,
you end up with a system which exhibits the properties of both messaging and
shared memory styles, depending upon the configuration of the architecture you’re
examining (obviously), but also depending upon how you look at it; sometimes
I see distributed objects with a uniform interface (the messaging view), and
sometimes I see interconnected pools of data (the shared memory view), and both
are perfectly valid and complementary ways of looking at a single configuration.
Some have referred to this duopoly as
“Bees and Ants”.
Ed Dumbill writes;
I’m wondering how long it will be before everybody’s completely reinvented RDF in the search for what it had all along.
Yup. Any day now, I expect. In fact, I bet BEA is working on
something as we speak given Adam’s comments, plus the recent
flurry
of
work
by
Dave Orchard.
Anybody who’s spent any time following RDF would know that there’s a
whole
bunch of
things
you could seriously mess up if you didn’t know better. Given that Dave and
Adam have previously demonstrated
some extreme ignorance
regarding RDF, I’m not hopeful that what they produce will be anything very
interesting.
WS-DataExtensibility anyone?
I also wanted to add, in response to Chris Ferris’
comment
about “partial understanding” (a key benefit of RDF) being unnecessary, that
partial understanding is little more than “MustIgnore”. How DaveO can go
on-and-on (see links above) about the value of MustIgnore, yet not see the
enormous value-add that RDF/XML provides over plain-old XML, totally boggles
my mind.
Sean spots an
old message of Don’s. Yup.
As yet another contribution to this discussion, here’s some light hearted
Jeff Foxworthy style “humour” (well,
my best go at it anyhow).
You know you might be using APIs, when a firewall is something you’re trying
to hide from, rather than something you’re trying to help.
You know you might be using APIs, when you’re generating stubs and skeletons
rather than reusing age-old network libraries.
You know you might be using APIs, when the words “transport” and “transfer”
are interchangeable in your architecture.
And, the number one … erm, wrong comedian …
You know you might be using APIs, when all your services have different, erm,
APIs.
Steve
has been an unwitting mentor of mine for almost ten years now.
I used to read his and Doug Schmidt‘s
articles
religiously in the mid 90s, and have enjoyed his more recent
work too. I’m sure his
weblog will be just as
insightful.
Welcome, Steve.
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.