On Wed, Jul 19, 2006 at 06:33:07PM +0000, Miciah Dashiel Butler Masters wrote: > On Wed, Jul 19, 2006 at 12:25:16PM -0600, Reid Rivenburgh wrote: > > 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'.
Well, it's all relative, I suppose. I'd like everything to be instantaneous, but I find the slight delays acceptable. It may be the case that there are times when the network or server are slow, making loading of a cached page slow, and I just accept it as the way it is. That seems rare, though. >From my perspective, it's also important to not show old, out-of-date pages. Another example is a site (www.huffingtonpost.com) that links from the main page to a second page with embedded named anchors; if the second page has been cached but I've reloaded the main page, the named anchor won't exist in the cached version of the second page, so I'll get an error dialog and have to reload the second page, go back to the main page, and re-click the link. Ugh. > 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. Sure, I understand that feature requests and "fixes" get done at the whim of the developers. I was just trying to raise the issue to the forefront. Frankly, for people who use ELinks to browse many web sites, the current state of things seems far from ideal. If ELinks is supposed to be used more to browse static documentation pages and things like that, I can see why it hasn't been noticed or deemed important. Reid _______________________________________________ elinks-users mailing list elinks-users@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-users
