Mailing List Archive

Re: Limited client-side caching
On Sunday 02 February 2003 12:56 am, Brion Vibber wrote:
> The browser still must check with the server to see if the page has
> changed, but if it hasn't the browser's cached version can be shown,
> saving a lot of database sorting, wikitext parsing, link checking, and
> bandwidth. If it has changed, you get the new version.

Everything is much faster now and that is great! But one minor annoyance is
that (at least with Konqueror 3.0.3) the New Messages message doesn't seem to
trigger the 'changed page' flag so Konqi dutifully displays the cached
version of a page instead of updating the page to display the new dynamic
content. No biggie though.

BTW, would it be possible to have the top header area be a different HTML
frame so that each frame can be dealt with separately? Then the content of
the page could be cached /server side/ after it is requested by an anon (or a
user with default settings) and served-up for anons and users with default
settings until a change is made to the page. Then the next anon/default user
accessing the page causes all the queries that are needed to render the new
page and then that page version is cached and made available to the next
anon/default user to view... The only thing that would be dynamic for anons
and default users would be the top frame (since it displays their IP/user
name and the 'new messages' link - but that could be cached client side so
long as the display of 'new messages' and changes in login status tells the
browser that that frame has changed). Just some thoughts - do with them as
you see fit.

--mav

WikiKarma
This was a bug report