On Wed, Jul 19, 2006 at 12:25:16PM -0600, Reid Rivenburgh wrote: > On Wed, Jul 19, 2006 at 06:05:35PM +0000, Miciah Dashiel Butler Masters wrote: > > [...] > > > > Do the browsers with which you are familiar actually check every time > > when you view a document (presumably using the HTTP If-Modified-Since > > header) whether there is a newer copy on the server? > > > > ELinks could do that, but it would be a little complex, and far too > > slow. I can't even stand the behaviour with ignore_cache_control > > disabled, which only affects documents that explicitely signal that they > > should be reloaded from the server. Such behaviour might be acceptable > > if done in the background, but then it would be a bit confusing (you > > load the document, you start to read it, then it suddenly updates while > > you're in the middling of reading it). > > My main browser is Firefox; I use ELinks under special circumstances. > Unfortunately, I'm really just a user and don't know how exactly Firefox > knows to reload a page. It does seem like there's some network activity, > so it probably is checking if there's a newer copy on the server. If > that's the case, I'm not sure why you think it would be so slow. I find > Firefox to be pretty fast, so ELinks should be at least as fast if it was > doing the same server query, no? Overall, it seems to me like ELinks is a > very fast browser, which should be no surprise since it's just text. When > loading a page, I personally would definitely trade a split-second of time > for the proper page. (I wouldn't want it to work as you describe, showing > the old page and then updating it in the background. I'd prefer > to wait.) Maybe this could be a setting for those that prefer speed and > don't ever use ELinks to visit frequently-changing pages? (Notice I'm > avoiding the whole issue of the complexity of implementing this...!)
The split-second delay would be mildly annoying, but that is the best case, when the server is responsive. How is the performance with slow servers? In any case, I do not consider Firefox to be anywere near 'pretty fast'. Doing what you describe might be feasible. It would be a little more code for the HTTP part and a little re-engineering of the cache code, but it doesn't sound too difficult. Whether it will actually get done also depends on whether the developers desire such behaviour, however. -- Miciah Masters <[EMAIL PROTECTED]> / <[EMAIL PROTECTED]> _______________________________________________ elinks-users mailing list elinks-users@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-users
