- From: M. Hedlund <hedlund@best.com>
- Date: Mon, 29 Jan 1996 18:28:23 -0800 (PST)
- To: Blake Sobiloff <bsobilof@inet.ed.gov>
- Cc: www-talk@w3.org
On Mon, 29 Jan 1996, Blake Sobiloff wrote: > >Advantages: > >* Doesn't stuff all possible variants into one document (avoids filesize > > bloat). > > I've heard a lot of people mention filesize bloat as a (potential) problem, > but I wonder how much of a problem it really is. I don't think it would be a problem for the average provider. I'm assuming, however, increasing complexity in the 'feature matrix' and increasing effort on the part of Web design houses (such as the one at which I work) to provide appropriate variations. > Also, how am I going to test each of the different structures -- keep > copies of the top five browsers for each platform handy? Yuck! I don't see how this <INSERT> proposal would be any different than any other content negotiation system in this respect. Are you arguing against HTML-feature-negotiation altogether? > >Disadvantages: > >* Requires multiple GETs (possibly a good number of them). > [...] > > This seems like a much more significant problem, especially given the > slow-start nature of TCP connections, plus the additional overhead with > older server architectures (threads vs. forks). I'm not denying that, but I am claiming that browsers new enough to implement <INSERT> will likely also be new enough to implement Connection: Keep-Alive. Parsing of <INSERT> is completely optional. I am _not_ arguing that <INSERT> is the best of all possible worlds. The best of all possible worlds would be published standards and no extensions -- which could be handled through Internet Media Type negotiation (that is, through the Accept: header). That scenario is obviously unrealistic. Therefore, I'm looking for the best solution that will allow for the following: * uneven browser feature implementations * flexibility given rapid feature innovation * cache-control * ease of implementation (for browser, server, and html authors) * backwards compatibility * avoidance of header bloat * minimized impact on browser/server performance Obviously, multiple GETs rate worst on the last point. I would argue that the other solutions proposed proposed rank a lot lower on many of the points above. We all seem to agree that no beautiful solution exists. Can we compare possible solutions based on their 'score' in the solution space described above? Marc Hedlund <hedlund@best.com>, <marc@organic.com>
Received on Monday, 29 January 1996 21:31:17 UTC