Date: Tue, 11 May 1999 14:04:14 -0700 From: "David Schwartz" <davids@webmaster.com> To: "Terry Lambert" <tlambert@primenet.com> Cc: <chat@FreeBSD.ORG> Subject: RE: Europe says yes to spam Message-ID: <000101be9bf1$d35c7cb0$021d85d1@whenever.youwant.to> In-Reply-To: <199905112050.NAA19560@usr04.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> FWIW, I believe something like this will be necessary, as more and > more companies "improve" their sites with "dynamic content", and > simultaneously suck the agregate banwidth down into the toilet. The basic idea is that it should be possible to work up a logical caching scheme were everybody wins. The operators of the caches benefit because they save bandwidth. The web page providers benefit because they save bandwidth. If caching is implemented properly, nobody loses. Hit counts can still be measured based upon the dynamic portions with as few actual bytes changing hands as possible. Unfortunately, at present, the only tool available to allow parts of a page to be cached and not others is frames (or custom java/javascript). And frames are ugly and awkward. If your only goal is to switch out a graphic on page views, the actual amount of dynamic content is small. The problem is that the graphic is in the middle of a page, and the rest of the page's contents are larger. I think a good solution would be something to allow browers to piece together pieces of pages using something similar to shtml. That way the browser could make a single connection to a caching proxy, get the static portion of the page, and then go on to request the rest of the page through the same connection with the cache acting as a 'pass through'. Perhaps something like : <DIV src="URL">Static alternative</DIV> It might take some work to make something like this look reasonable while the page is loading though. That way the majority of the data could be made static and only the truly dynamic portions would have to be refetched. David Schwartz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000101be9bf1$d35c7cb0$021d85d1>