Well, remember that in the FHTTP model the delivery stream of the
document is separate from the delivery stream for the meta-information;
and if the client could completely avoid having to look in the document
delivery stream for pointers on what to do, that would seem to be a good
thing (though maybe I'm misinterpreting the model.)
Also, I think we should be thinking along the lines of making HTML and HTTP
as orthogonal as possible - HTTP should be as completely functional when the
WWW is SGML aware, too.
> If we intend for the server to parse documents and take action before the
> client has determined what they will do with the information, there will need
> to be some additional dialog upfront where the client can communicate its
> "intentions" about the information it has requested. e.g. I'd rather have
> 10,000 clients parse the document and determine what actions to take than
> to have the server parse the same document 10,000 times while the next 10,000
> requests are waiting.
Remember that I suggested the server only parse the document once and
cache that info for later accesses, not parse it with each access (though
doing a quick stat to see if the file had changed would be needed, but I
think that's done somewhere in the process anyways for the last-modified
line).
> Best of all I'd rather have the document author wait
> while their document is checked for errors and optimized for rapid retrieval
> just once so all 10,000 of us could enjoy the benefits.
Which brings up the idea again that the HTML the client sees should possibly
be different than the HTML the author creates. That sounds fine, I'd
just counter that it might not be the right level of generalization....
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Your slick hype/tripe/wipedisk/zipped/zippy/whine/online/sign.on.the.ish/oil
pill/roadkill/grease.slick/neat.trick is great for what it is. -- Wired Fan #3
brian@hotwired.com brian@hyperreal.com http://www.hotwired.com/Staff/brian/