My conception of the current OPES approach is that your language
translation service would have the the intermediary figure out when
to vector the message (rule-based), but would not assure protocol
semantics; therefore, the futzing with the entity headers, etc. would
be done by the service, not the intermediary. And we're both saying
that this is a Bad Thing.
Ah, interesting. I agree that it's a bad thing if we're talking about
encapsulation ala ICAP. I disagree if this service is just another
intermediary, and obeys the end-to-end model of the protocol in use
(though from what I've seen, that isn't the assumed case for OPES).
Definately; that's where I'm going with it. But you need to do
inference; the above is all completely declarative; it just overlays
logic onto contexts to build rules; then you run them against
statements extracted from messages like
:http_request headers:accept_language ("en", "fr")
:http_request log:uri [ uri:scheme "http" ; uri:authority [
uri:host "www.example.org" ; uri:port "80" ] ; uri:path "/foo" ] .
and so forth. See [2].
Ok, that's descriptive, I think (not sure what "log:uri" means). Your
previous example was prescriptive (e.g. "opes:invoke" as the verb).
That's what confused me.
Roy Fielding identified three types of headers[1]; two of these
(the ones called "metadata") are statements about things as well.
[1]
http://www.ebuilt.com/fielding/pubs/dissertation/rest_arch_style.htm#tab_5_1
But I digress ...
Oh, that's not a digression at all; I think it's a critical
distinction for efforts like OPES. I can see attempts at doing this
in 2616 (entity/general/request/response headers), but Roy's approach
is much clearer, and it would be even nicer if there was a more solid
differentiation, as he suggests.
I had tossed around the idea of providing some extension headers for
this such as;
Resource-Header
Representation-Header
Control-Header
The values would be other header names. For example, "Content-Type"
would be an assumed value of Representation-Header. This would allow
intermediaries to be smarter about extension header management. So for
example, caches wouldn't go caching extension control headers, but
could cache extension resource or representation headers. But I came
to the conclusion that the cat is out of the bag already; you can't
assume that the use of those headers will do what you want, so why
bother? Maybe a mandatory extension mechanism is important after all.
8-)
MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA. mbaker(_at_)planetfred(_dot_)com
http://www.markbaker.ca http://www.planetfred.com