lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Lynx-dev] [A]lways [O]ptions


From: Stef Caunter
Subject: [Lynx-dev] [A]lways [O]ptions
Date: Wed, 12 Jan 2005 21:54:12 -0500 (EST)

I'm doing some more lynx documentation... and just dealing with initial
approaches to lynx:

userdefs.h

Default settings for in particular INFOSECS, ALERTSECS and MESSAGESECS
and COOKIE are things that cause lynx to "sit there" instead of being fast and
light. This might sound whiny as it pertains to stuff that is
readily configurable in userdefs.h (and elsewhere), but I know that lynx is
incredibly fast at displaying pages and I wish it were like that by default.
While for example linux distros could set stuff like this, they tend to just
make STARTFILE their home page and consider it done (guess who).

I am assuming that most knowledgeable lynx users have configs they like that
deal with these setup issues adequately.

Notwithstanding, in userdefs.h:

ALERTSECS is too long at 3 seconds. For a new user, I suggest that the
displayed messages will not mean a lot anyway. Same for MESSAGESECS. Zero them
all, and let the page load.

The "ACCEPT_ALL_COOKIES" setting; (I know we've gone over this in the
past). This wouldn't be of consequence but I see over and over that this delays
unacceptably the display of a page that should load almost instantly because it
happens to want to set a cookie (I use lynx at various times to teach community
college students).

I know that the lynx user base is far more diverse than this, but acknowledging
that most user's first experience with lynx is with a default, unoptimized
install it might be preferred to have the browser work quickly first, and show
information secondarily if desired. To some extent it is the other way around
right now.

Any default acceptance of all cookies is again for page load
purposes. While requesting user intervention is a time-honoured tradition among
browsers I am not sure it is entirely necessary. Most users will tolerate the
back and forth of a cookie (if they even know about it) if they see better
server responses (eventually being recognized by a subscription
site, etc.). Again, knowledgeable users already have settings they like and
control, and I am not requesting removal of functionality, just a change in the
default. This can always be toggled at compile time to restore the prompting.

LYCookie/LYOptions

The other possibility for cookies (not just changing userdefs.h) would be to
have "[A]lways allow" trigger an [O]ptions page (re)generation of .lynxrc to
make always be always. As I read the code, [A]lways means for the lynx session;
LYCookie doesn't do a disk write of .lynxrc; only an [O]ptions "flush" to disk
is truly permanent.

Can a [F]orever setting in the cookie handling function be set to call the
[O]ptions write to disk of .lynxrc? The LYOptions disk write appears to be
accomplished with a POST to the special LYNXOPTIONS: URL - is it a pain to put
that in?

--

__Stef

http://caunter.ca/contact.html




reply via email to

[Prev in Thread] Current Thread [Next in Thread]