Re: [elinks-users] Cache problems?

2006-07-19 Thread Miciah Dashiel Butler Masters
On Fri, Jul 14, 2006 at 01:41:38PM -0600, Reid Rivenburgh wrote:
 On Fri, Jul 14, 2006 at 06:39:23AM +, Miciah Dashiel Butler Masters wrote:
  On Thu, Jul 13, 2006 at 03:54:28PM -0600, Reid Rivenburgh wrote:
   Hi.  I've been using elinks for awhile now; it seems like the best of the
   text browsers.  But I've noticed one problem, and I haven't seen any bug
   reports or emails relating to it.  
   
   I seem to be having cache problems.  When I visit www.dailykos.com (for
   example) and click to view an article, if I then click on www.dailykos.com
   on the article page to go to the home page again (i.e. NOT going back in
   the history), the page I get seems to be the cached version from before.
   It's very fast and doesn't seem to access the network.  The content on the
   home page changes frequently, so it's often out of date, requiring me to
   reload manually.  I've set the formatted documents number and memory cache
   size to zero to try to fix this, but it still happens.  Is it possible
   that this only happens to me for some reason?
   
   I'm currently using the latest 0.12 from 20060712, but it happened with
   0.11 and 0.10.
  
  Go to Setup - Options manager - Document - Cache - Ignore
  cache-control info from server and set that option to 0.
 
 I forgot about that option.  That's already set to 0.

When you say 'already', do you mean that you have the problem even with
the option disabled?

-- 
Miciah Masters [EMAIL PROTECTED] / [EMAIL PROTECTED]
___
elinks-users mailing list
elinks-users@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-users


Re: [elinks-users] Cache problems?

2006-07-19 Thread Reid Rivenburgh
On Wed, Jul 19, 2006 at 05:32:19PM +, Miciah Dashiel Butler Masters wrote:
 On Fri, Jul 14, 2006 at 01:41:38PM -0600, Reid Rivenburgh wrote:
  On Fri, Jul 14, 2006 at 06:39:23AM +, Miciah Dashiel Butler Masters 
  wrote:
   Go to Setup - Options manager - Document - Cache - Ignore
   cache-control info from server and set that option to 0.
  
  I forgot about that option.  That's already set to 0.
 
 When you say 'already', do you mean that you have the problem even with
 the option disabled?

Yes, that's what I meant.  Sorry about the confusion.

Reid
___
elinks-users mailing list
elinks-users@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-users


Re: [elinks-users] Cache problems?

2006-07-19 Thread Reid Rivenburgh
On Wed, Jul 19, 2006 at 06:05:35PM +, Miciah Dashiel Butler Masters wrote:
 Looking at the document, I don't see any headers to indicate that ELinks
 should reload it:
 
HTTP/1.1 200 OK
Date: Wed, 19 Jul 2006 17:42:19 GMT
Server: Apache/1.3.34 (Unix) mod_gzip/1.3.26.1a
Vary: Accept-Encoding
Last-Modified: Wed, 19 Jul 2006 17:42:01 GMT
ETag: 8d4622-c8b2-44be6ee9
Accept-Ranges: bytes
Connection: close
Content-Type: text/html
Content-Encoding: gzip
Content-Length: 18374
 
 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...!)

Reid
___
elinks-users mailing list
elinks-users@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-users


Re: [elinks-users] Cache problems?

2006-07-19 Thread Miciah Dashiel Butler Masters
On Wed, Jul 19, 2006 at 12:25:16PM -0600, Reid Rivenburgh wrote:
 On Wed, Jul 19, 2006 at 06:05:35PM +, 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


Re: [elinks-users] Cache problems?

2006-07-19 Thread Reid Rivenburgh
On Wed, Jul 19, 2006 at 06:33:07PM +, 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


Re: [elinks-users] Cache problems?

2006-07-19 Thread cga2000
On Wed, Jul 19, 2006 at 02:05:35PM EDT, 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?
 
In mozilla it's customizable. Under Preferences  Advanced  Cache, you
have the following options:

Compare the page in the cache to the page on the network:

. Every time I view the page
. When the page is out of date
. Once per session
. Never

I assume this to really mean.. :-) 'obtain and display' the page from
the server in lieu of the one in the cache.. under the above
circumstances.. rather than 'compare' which is not the same thing.

Sorry for being splitting hairs.

 ELinks could do that, but it would be a little complex, and far too
 slow. 

Not really.  I hit Ctrl-R all the time when accessing news sites where
the contents change frequently and on a decent broadband connection
*and* provided the server is responsive.. this does not result in any
noticeable delay.  IOW the reloading does not feel like it adds
anything to the Ctrl-R action.

OTOH doing the same thing in mozilla is quite slow on my machine.. not
because of the time it takes to fetch a new version but appently because
of the rendering (PIII 650MHz).  This is one of the main reasons I have
switched to elinks for pratcticall all web browsing.. couldn't put up
with mozilla executing its million lines of code every time I displayed
a new page.

 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. 

I'm not sure what this is supposed to do.  I set this flag to '0' as
suggested in an earlier post and even though I cycled elinks I have not
noticed a change in behavior.

 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).

The main problem that I have - even with pages whose contents do not
change frequently such as an online docs/manuals is that the links on
the page do not switch to their 'visited' color.. which sometimes makes
it a bit confusing.. but no big deal, since I have gotten used to
Ctrl-R'ing all the time without thinking.

Since this mainly poses problem when hitting the back key - 'h' - maybe
I should find a way to map this to a short script/macro that just does
'back'+'reload'?

Hope the above is relevant.

Thanks

cga
___
elinks-users mailing list
elinks-users@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-users


Re: [elinks-users] Cache problems?

2006-07-19 Thread Reid Rivenburgh
On Wed, Jul 19, 2006 at 04:36:29PM -0400, cga2000 wrote:
 OTOH doing the same thing in mozilla is quite slow on my machine.. not
 because of the time it takes to fetch a new version but appently because
 of the rendering (PIII 650MHz).  This is one of the main reasons I have
 switched to elinks for pratcticall all web browsing.. couldn't put up
 with mozilla executing its million lines of code every time I displayed
 a new page.

I understand your grief.  The very latest Firefox alpha or beta seems
quite a bit better in that regard; you might want to give it a try.

 Since this mainly poses problem when hitting the back key - 'h' - maybe
 I should find a way to map this to a short script/macro that just does
 'back'+'reload'?

As someone mentioned earlier, you can use the keybinding manager to
associate back with Follow the current link, forcing reload of the
target.  I think that's what you want.  Unfortunately, I use the mouse to
navigate pages, and I don't think there's any way at the moment to
configure actions called by mouse clicks.

reid
___
elinks-users mailing list
elinks-users@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-users


Re: [elinks-users] Cache problems?

2006-07-19 Thread cga2000
On Wed, Jul 19, 2006 at 04:43:30PM EDT, Reid Rivenburgh wrote:
 On Wed, Jul 19, 2006 at 04:36:29PM -0400, cga2000 wrote:
  OTOH doing the same thing in mozilla is quite slow on my machine.. not
  because of the time it takes to fetch a new version but appently because
  of the rendering (PIII 650MHz).  This is one of the main reasons I have
  switched to elinks for pratcticall all web browsing.. couldn't put up
  with mozilla executing its million lines of code every time I displayed
  a new page.
 
 I understand your grief.  

:-)

 The very latest Firefox alpha or beta seems
 quite a bit better in that regard; you might want to give it a try.

I've also heard that the SpiderMonkey - the new mozilla has marked
improvements in the area.  But slow rendering was only one of the
issues.  I have switched to a keyboard-only text-mode 'desktop' -
interface, I should say and I am a much happier man. 
 
  Since this mainly poses problem when hitting the back key - 'h' - maybe
  I should find a way to map this to a short script/macro that just does
  'back'+'reload'?
 
 As someone mentioned earlier, you can use the keybinding manager to
 associate back with Follow the current link, forcing reload of the
 target.  I think that's what you want.  Unfortunately, I use the mouse to
 navigate pages, and I don't think there's any way at the moment to
 configure actions called by mouse clicks.
 
Drop the mouse man..! Charles Darwin is categorical.. You'll never grow
a third arm in your lifetime.

Oh.. and as to developers being 'whimsical' relative to enhancements, I
think not.. That's exactly why I barged into your thread.. The list is
really the place where you can voice an opinion.. and since this
caching behavior was something that struck me as being fundamentally
different from the other browser..  Not sure it's a bad thing, though..
I briefly mentioned it but Miciah has a good point.. when the server is
unresponsive it's OK I guess if you explicitly ask for a reload..
Maybe less so when the reload is done on a transparent basis every time
you hit the back button (eg.).

Thanks

cga
___
elinks-users mailing list
elinks-users@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-users


Re: [elinks-users] Cache problems?

2006-07-19 Thread cga2000
On Wed, Jul 19, 2006 at 05:31:42PM EDT, Reid Rivenburgh wrote:
 On Wed, Jul 19, 2006 at 05:10:42PM -0400, cga2000 wrote:
  I've also heard that the SpiderMonkey - the new mozilla has marked
  improvements in the area.  But slow rendering was only one of the
  issues.  I have switched to a keyboard-only text-mode 'desktop' -
  interface, I should say and I am a much happier man. 
 
 Nice.  I don't think I could get by with text-only in my main browser
 FYI, I think there's a Firefox extension that is aimed at keyboard-only
 use.  Never used it, though.

I'll look it up.. Although I'm sceptical.. Microsoft did a very good job
of making gui's navigable via the keyboard but you cannot change the
fact that the gui designer was thinking *mouse* when he designed the
layout.. etc.  Just and example.. in many guis I have seen you may have
to drill down three.. four.. five..? levels of dialog/popup boxes the
size of a postage stamp (some of them you'll even have to reach for that
scrollbar so you can get to what you're looking for..) before you
eventually get to the particular flag or whatever that you want to
change.. While this is perfectly suitable with the inherent slowness of
the mouse, it becomes rather annnoying when you use a considerably
faster interface like the keyboard.
 
  Drop the mouse man..! Charles Darwin is categorical.. You'll never
  grow a third arm in your lifetime.
 
 Oh it's no problem, I use my tail to control the mouse! :)
 
:-)

Not that I'm particularly happy with the keyboard either.  The
traditional typewriter keyboard was bad enough but what IBM did to it is
beyond words..

Only solace I find in a keyboard-only environment is its relative
simplicity (as compared with keyboard+mouse) .. Even a fairly large
number of inconsistant keyboard shortcuts across applications is in my
case a tad more efficient than switching action mode every other second.

  Oh.. and as to developers being 'whimsical' relative to enhancements, I
  think not.. That's exactly why I barged into your thread.. The list is
  really the place where you can voice an opinion.. and since this caching
  behavior was something that struck me as being fundamentally different
  from the other browser..  Not sure it's a bad thing, though..  I briefly
  mentioned it but Miciah has a good point.. when the server is
  unresponsive it's OK I guess if you explicitly ask for a reload..  Maybe
  less so when the reload is done on a transparent basis every time you
  hit the back button (eg.).
 
 I guess whims was a bad word to use.  

so far they haven't objected...

 I just wanted to explain that I
 understand it's open source and that the developers can do what they like.

I don't think they may.. or can.

Whatever they may state in their disclaimers they just cannot pull the
plug on a piece of software that has some degree of following...  

And in fact they very rarely do so..  one of the nice things about OSS
is that when it happens someone else will step in.. if the software is
worth the effort.. that is.. (?)

As to *being able* to do what they like.. it's pretty much the same
thing..  too much change that turns out to be unsatisfactory and the
user community will just not take it.. someone forks the project.. etc.

.. like .. I'm a vim user/fan.. now Bram Moolenaar et al. all of a
sudden see the light and the next version of Vim turns out to be an MS
Word clone...  how 'bout that?

I do hope someone will implement/improve CSS rendering some time soon,
though..  Not that I spend much time on commercial web sites.. but a
growing number are getting hard to read.

Yeah.. that's how you eventually get them to pay attention.. 

.. moan consistently on the list with a bunch of other troublemakers
until they really get sick of it..

OK.. fixed in CVS - GIT, I mean.. 

now p*ss off..

:-)

 Sure, having a discussion on this list is one way to convince them that
 your way is the right way!  (So here goes:)
 

 As for the cache issue, I think the current method is not good from a
 usability standpoint.  It sounds like he and I use ELinks in different
 ways so he doesn't run into this problem often, plus he places a lot of
 value on speed.  I think if Mozilla or Firefox worked the same way, the
 majority of users would be up in arms!  

.. interesting point.. but then they have been conditioned by years of
IE ( Netscape) abuse in so many ways..  

So that may or may not be an argument..

I found this behavior a bit disconcerting at first but after a couple of
weeks I've grown used to it.

As mentioned in an earlier post, and provided I fully understand the
issue, this would appear to be something that can be customized in
mozilla..  don't know about FF, though.

 So if I was in charge of ELinks
 development, I'd make the Mozilla compare automatically (or whatever it
 is) be the default but put in Mozilla's other settings as options.  Then
 everyone could be happy.

.. and call the option something else rather than 

Re: [elinks-users] Cache problems?

2006-07-19 Thread Miciah Dashiel Butler Masters
On Wed, Jul 19, 2006 at 09:44:41PM -0400, cga2000 wrote:
 On Wed, Jul 19, 2006 at 05:31:42PM EDT, Reid Rivenburgh wrote:
  On Wed, Jul 19, 2006 at 05:10:42PM -0400, cga2000 wrote:
   I've also heard that the SpiderMonkey - the new mozilla has marked
   improvements in the area.  But slow rendering was only one of the
   issues.  I have switched to a keyboard-only text-mode 'desktop' -
   interface, I should say and I am a much happier man. 
  
  Nice.  I don't think I could get by with text-only in my main browser
  FYI, I think there's a Firefox extension that is aimed at keyboard-only
  use.  Never used it, though.
 
 I'll look it up.. Although I'm sceptical.. Microsoft did a very good job
 of making gui's navigable via the keyboard but you cannot change the
 fact that the gui designer was thinking *mouse* when he designed the
 layout.. etc.  Just and example.. in many guis I have seen you may have
 to drill down three.. four.. five..? levels of dialog/popup boxes the
 size of a postage stamp (some of them you'll even have to reach for that
 scrollbar so you can get to what you're looking for..) before you
 eventually get to the particular flag or whatever that you want to
 change.. While this is perfectly suitable with the inherent slowness of
 the mouse, it becomes rather annnoying when you use a considerably
 faster interface like the keyboard.

This is why why have keyboard accelerators.

   Drop the mouse man..! Charles Darwin is categorical.. You'll never
   grow a third arm in your lifetime.
  
  Oh it's no problem, I use my tail to control the mouse! :)
  
 :-)
 
 Not that I'm particularly happy with the keyboard either.  The
 traditional typewriter keyboard was bad enough but what IBM did to it is
 beyond words..

What did IBM do?

 Only solace I find in a keyboard-only environment is its relative
 simplicity (as compared with keyboard+mouse) .. Even a fairly large
 number of inconsistant keyboard shortcuts across applications is in my
 case a tad more efficient than switching action mode every other second.

I prefer to be able to form my environment to myself, you know, like a
human. Using GNU Screen, my Web browser, E-mail, IRC client, shells,
editors, music player, c.  are each exactly one keypress away. Each
program is customised (mostly) with comfortable (for me) keybindings.

   Oh.. and as to developers being 'whimsical' relative to enhancements, I
   think not.. That's exactly why I barged into your thread.. The list is
   really the place where you can voice an opinion.. and since this caching
   behavior was something that struck me as being fundamentally different
   from the other browser..  Not sure it's a bad thing, though..  I briefly
   mentioned it but Miciah has a good point.. when the server is
   unresponsive it's OK I guess if you explicitly ask for a reload..  Maybe
   less so when the reload is done on a transparent basis every time you
   hit the back button (eg.).
  
  I guess whims was a bad word to use.  
 
 so far they haven't objected...

How offensive, implying that we have whims! In fact, developers have
itches and occasional fancies, but none of this whim nonsense.

  I just wanted to explain that I
  understand it's open source and that the developers can do what they like.
 
 I don't think they may.. or can.
 
 Whatever they may state in their disclaimers they just cannot pull the
 plug on a piece of software that has some degree of following...  
 
 And in fact they very rarely do so..  one of the nice things about OSS
 is that when it happens someone else will step in.. if the software is
 worth the effort.. that is.. (?)

Guess how ELinks got started? See http://elinks.cz/history.html.
The impetus for ELinks was largly that it looked like Links had been
abandoned.

 As to *being able* to do what they like.. it's pretty much the same
 thing..  too much change that turns out to be unsatisfactory and the
 user community will just not take it.. someone forks the project.. etc.

ELinks was forked also because Links's developer was very strict with
regard to patches.

 .. like .. I'm a vim user/fan.. now Bram Moolenaar et al. all of a
 sudden see the light and the next version of Vim turns out to be an MS
 Word clone...  how 'bout that?

It is getting there, but at least Vim still runs on the terminal.

 I do hope someone will implement/improve CSS rendering some time soon,
 though..  Not that I spend much time on commercial web sites.. but a
 growing number are getting hard to read.

The developers hope for that too. However, most of them work, most of
them are students, and better CSS support requires DOM support and a box
model and stuff that all requires a lot of coding effort. We would all
like to get this done, but don't get your hopes too high.

 Yeah.. that's how you eventually get them to pay attention.. 
 
 .. moan consistently on the list with a bunch of other troublemakers
 until they really get sick of it..
 
 OK.. fixed in CVS - GIT, I mean..