Roy> Right, but it only does that for HTML documents being served by an HTTP
Roy> server. Outside of that context, it simply doesn't make sense to use
Roy> the HTML syntax of the META construct.
But it makes no sense to define the syntax without reference to the META
syntax if it is intended that SOAPs have the ability to be encoded within a
META. I could probably come up a syntax exactly more appropriate to the
SOAP model, but unless it is compatible with the HTTP header syntax, I've
lost a desired design specification.
Roy> If the SOAPs are located in some external source (file or database or
Roy> nameserver), then the syntax should be appropriate for that source
Roy> (table entries, database records, linked lists, etc.). Defining them
Roy> using HTML syntax only confuses the matter.
I agree, but, again, the SOAP naming syntax must not preclude transmission
in either the request or response of an HTTP transaction. This is the main
reason I was discussing the syntax in terms of the META syntax, because the
META syntax automatically provides HTTP compliance.
Roy> It would be easier for the reader (me) if you just present the output
Roy> (i.e. the actual header) and don't worry about the syntax of how it is
Roy> stored.
Ok, understood; you've made a good point. Please realize that a great deal
of the things I write were thought up while I wrote the document. I
apologize for forcing others to listen to my ramblings while I thrash out
some ideas over the course of my letter. But answering queries like yours
really help me to refine the ideas. I didn't realize exactly what I was
looking for (a SOAP naming syntax compatible with HTTP request/object header
transmission) until started answering this letter.
JRhine> The model I'm proposing is to construct the information that would
JRhine> normally be contained within the META tag via a dynamic lookup on a
JRhine> distributed database backend (the RLS).
Roy> Such a solution would also be inadequate for non-HTML documents
Roy> (e.g. MPEG movies or GIFs).
JRhine> I certainly don't see why that is the case; if the transactions
JRhine> headers (the moral equivalent of the META tag, in my mind) are
JRhine> constructed from information external to the object, how in any way
JRhine> would that not apply to MPEGs or GIFs?
Roy> There is no equivalent way to embed such information in a GIF without
Roy> changing the GIF specification.
Once again, I _do not_ wish to embed this metainformation in the document,
even within the META element. The vast majority of headers I wish to
generate will be generated on the fly by the server. Thus, it does not
matter at all that I can't encode the META element within the GIF syntax. I
don't want to.
Roy> The only way to provide such information for GIFs (and any other
Roy> non-HTML format document) to the server for use as header information
Roy> is to provide it via external tables (whether those tables be in the
Roy> form of a flat file, database, or DNS lookups).
JRhine> I want something slightly more complex than a table; I want a dynamic
JRhine> database query, possibly constructed from information obtained via
JRhine> distributed means (not every server will be able to store all the
JRhine> information for all documents).
Roy> Well, this has little to do with the rest of this discussion, but I
Roy> think you are trying to do too much here. If retrieving a document
Roy> (particularly via hypertext) requires multiple DNS-type lookups to
Roy> remote sites, then SOAPs will become a curse of death.
I don't think the goals should be abandoned because current implementations
of distributed information system backends are weak. IHMO, DNS provides
extremely good service considered the task it is faced with. Consider, your
already doing a DNS lookup every time you make a connection; how horrible is
the response there. As with DNS, there should be secondary servers,
providing redundancy of service for large portions of the SOAP space.
Caching will also improve response. You can cache a lot of SOAPs; they are
generally much smaller than the documents that current Web caching
prototypes are caching.
If performance actually turned out to be abismal (and I refuse to accept
that as a foregone conclusion), then you would simply lower the number of
SOAPs that you are applying to a particular search. The user is already
prepared to wait a little while; they are performing a search, after all.
And extra second or two to apply all the SOAPs isn't going to be "a curse of
death".
Roy> Even one such lookup (beyond that of finding the original document)
Roy> would be longer than a typical user is willing to wait for a document.
I don't understand the assumption that performance will be horrible. It is
effectively a DNS lookup; what's the longest you've waited to resolve a
hostname? Obviously current Web users don't think it excessive; they seem
instead to be increasing their utilization of the system.
Roy> Further, if the document providers did not have control over what SOAPs
Roy> are applied, then an unethical user could kill any document by simply
Roy> applying several SOAPs to it -- the nature of the SOAPs wouldn't matter
Roy> -- just their existance would be enough to kill the server.
What? SOAPs are applied by the end user; no one but me can select what
SOAPs are applied to my search. And no server is required to serve SOAPs
from anyone who wants to register a SOAP. If someone wishes to issue a
SOAP, they are responsible for providing the resources necessary to serve
that SOAP.
Roy> The only practical solution is to allow the document provider to
Roy> control what SOAPs are applied and to store those SOAPs at the same
Roy> location as the document.
In all honesty, you have not convinced me a bit. Could you cogently review
the reasons you think external, distributed SOAPs are not feasible, and why
those problems don't apply to other distributed object systems?
JRhine> Note also that the Interpedia project has not (yet) made the
JRhine> assumption that a SOAP must expire when a document version changes,
JRhine> since the question of implied SOAPs is still open. Yes, yes, it
JRhine> seems the logical thing to do, and many documents will operate that
JRhine> way by default, but I have yet to be convinced that it applies in
JRhine> all cases. I won't sacrifice SOAP reliability to gain a minor
JRhine> advantage, though.
Roy> Really? I'd think this would be obvious. E.g., if version 3.1 is
Roy> given the SOAP American_Children's_Association!
Roy> suitable-for-children=true and version 3.2 contains (whether
Roy> accidentally or purposely) a pornographic picture, and the SOAP is
Roy> automatically carried forward, then the American Children's Association
Roy> becomes criminally liable for contributing to the delinquency of
Roy> minors.
Oh, please. One, as I clearly stated, by far the vast majority of the
documents, such as the situation you describe, would _default_ to expiring a
SOAP upon any change in the source document. Second, I am not criminally
liable for advocating any type of behavior I wish.
Roy> Absolutely nobody in their right mind gives a real Seal of Approval
Roy> without first inspecting the specific version of the product given
Roy> approval.
Ok, how about a document which is published by the same organization which
issues the SOAP? One mechanism is cluttering up the SOAP space by issuing
an entirely new SOAP for this document and duplicating a lot of information
(unless we come up with a good property inheritance scheme). Or one could
define that any version 3.x of this document has been approved. The latter
mechansim is cleaner, more powerful, and scales better.
All I am claiming is that it _might_ be desireable to have inherited SOAPs
(or even SOAP property inheritance). It's just not my style to assume
certain paradigms are the only way of doing something or that the convential
wisdom is always correct. I don't design any system which precludes future
expansion and I won't do it with the SOAP specification. At this early in
the development of any project, brainstorming is essential.
Roy> BTW, I just noticed the use of an apostrophe in that SOAP. I'd be
Roy> surprised if that is an allowable character in your naming scheme.
Currently, the only specification I've made is that the bang is the path
separator, the equal sign is reserved key/content separation (well,
actually, I just now specified that) and the character set is defined is
defined by RFC 822 (possibly ISO LATIN 1, as allowed by the HTTP spec).
Thus, apostrophe's are allowed, as are spaces, for that matter. It's not
_my_ naming scheme; it's HTTP's.
JRhine> Is there any particular advantage to grouping all the SOAPs on a
JRhine> single header field instead of using multiple header fields, one per
JRhine> SOAP?
Roy> Nope, I just think it looks better and I wanted to show an example of
Roy> using multiple data items (separated by comma and/or whitespace) in one
Roy> header.
Thanks; I hadn't considered the option before.
Roy> Even with multiple SOAP headers, this is what you should get back from
Roy> an rfc822 parser.
I didn't know there was a RFC 822 specification that multiple headers should
be squished into a single key/content value to be passed to the client. Is
this what normally happens with Received headers? None of the parsers I've
ever written have done that, and upon a second look, I fail to find anything
in section 3 of RFC 822. Could you provide some more detailed references
that would support your assertion?
--
Jared Rhine [email protected]
wibstr Harvey Mudd College
http://www.hmc.edu/www/people/jared.html
"To hear many religious people talk, one would think God created the
torso, head, legs and arms, but the devil slapped on the genitals."
-- Don Schrader