:) > :) 3. New HTML elements
:) > :) ---------------------
:) > [.. desc deleted ..]
:) > This is much closer to what I would like to see happen.
:) > But perhaps the *server* could negotiate and decide on some aspect of
:) > *what* to send before that, that would definitely speed things up.
:) > I would suggest some form of client-server negotiation prior to delivery
:) > so that the client and server are doing some of the job and allowing the
:) > best use of net and system.
:)
:) I'm reluctant to on solutions that require extra work on the servers
:) part. Reason is that servers already have much work to do handle
:) multiple http connections at a given instance (plus handle CGI).
:) Adding more task for servers to do will just bog things down.
Actually, if you think about it, the server does *less* in the "normal" (:))
case if you allow "pre-negotiation of capabilities" -- a lot of delivery
will not be necessary at all. If you're doing the "if-else" case above,
the responsibility on the client which doesn't handle the "gif" doesn't
even need to ask the server, so no negotiation is necessary. However,
if the capability is required for the document, and the client doesn't
handle it, why deliver it at all? or at least the part necessary (in
document stuff, not "hyper-linked" in stuff :)).
:) Also, servers provide other data than just HTML, why should servers
:) have to treat HTML special over other media types it might provide?
:) Media types should be self-sufficient and not require special server
:) processing. However, if HTML and HTTP are not meant to be mutual
:) exclusive ...
And who says what is done for negotiation has to be limited to HTML :).
If this is done, it'll become an extension of the server protocol which
others can use. [Oh no, yet another extension]
-- [Daneel Pang] | Eventually, everything will be there. [email protected] | Big is beautiful, big is accomodating. (65)770-3801 | I needed it yesterday.