[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LYNX-DEV new to LYNX
Re: LYNX-DEV new to LYNX
Sat, 20 Sep 1997 13:03:43 +0100 (BST)
Jim Dennis wrote:
(First an aside: this was copied to address@hidden - I suspect this is
equivalent to the help address. Although I think there has been a change
in the mailing list software in the last few days to get round this, doing
a group reply to mail injected through the help address almost certainly
will not result in it reaching the questioner.)
> > Will I be able to browse the FULL INTERNET using LYNX?
> > I am using LYNX at my job, and the computer does not have window!
> The web is not the FULL INTERNET!
Lots of good points.
> Basically there are some sites that are "unfriendly." They
> make gratuitous use of tables, imagemaps, frames, Java applets,
> and ISAPI, and other extensions. They hope to win in some
> "one-up-manship" contest of "coolness."
active server pages are neutral technology, and include the CGI pages
that made the web interactive. Even Microsoft's Active Server Pages
product is neutral, although that product does make it easier for the
technically unsophisticated to discriminate between browsers (which
though controversial in the Lynx community is not necessarily a bad thing,
if done with the right motives - i.e. give Lynx a clean text only page,
which then simultaneously meets the marketing department's mandates to
use the latest gimmicks and makes the pages accessible to Lynx users).
ISAPI is as neutral as CGI; it is just a more efficient way of doing
CGI type functions.
All can be abused, but you can discriminate between browsers under the
Apache server with BROWSERMATCH and a CGI script, or by directly reading
the user agent from the environment variables, also in a CGI script, but
with any server at all.
> Some sites are "just too cool" to have any textual content -- and
> shove a message down your throat:
> "Go get a 'real' browser, punk!"
There certainly are sites, as I mentioned earlier, which do text as graphics
(note that the link I quoted will no longer be the link of the week, and it
is almost certain that the real fault lies with the ISP rather than the page
author - the ISP is probably providing a toolkit - the home page is certainly
being served without a last modified date, making it uncacheable++).
However messages like this are often the result of the misuse of features
intended to provide a graceful fallback for less capable browsers. I don't
think <NOFRAMES> was put in there to advertise the latest version of
MSIE or Navigator; it was put there so that one could repeat the contents
list for non-frames browser, or describe the structure of the frameset, with
links to the individual frames.
> and can fetch some sorts of "map" files (the text files which
> describe the "hot" (clickable) regions of an IMAGEMAP -- which
> is a picture with "clickable" point therein) -- so you can browse
Client side image maps are actually embedded in the page. I think
they were really invented because they allow the web to scale better -
server side image maps always require an end to end interaction with the
server, and also required a quite expensive CGI process on early servers.
Scaling of the "internet" to the cable TV type market really requires that
most requests are satisfied from the cable head end, without involving
the original server.
However, client side maps have benefits to GUI browsers which are generally
also benefits to Lynx. For the GUI browser, they allow feed back on the
hot zones; for both, they allow feedback on which URL will be accessed;
for both, but subject to confimation, they can provide feedback in the
form of a title for the link, although this tends to fall into the same
category as alt strings, which nowadays also provide "tooltips" feedback,
but are rarely used.
> them. Lynx can offer to accept cookies *<see note: cookies> for a
> given session -- and, eventually, may offer options to save them.
In my view, most of the legitimate uses of cookies only require a single
session lifetime. The marginal case is that typified by the use claimed in
Alta Vista's privacy statement, i.e. advertisement rotation. Long term
tracking of users, other than for pure market research, is probably better
done by forcing them to explicitly logon, e.g. using the HTTP authentication
> developers a crude and unreliable way to
> "maintain state" (distinguish between
Although a lot of this paragraph is true, "maintaining state" is a
legitimate need for many applications, although arguably HTTP was never
intended for such applications. It simply means being able to save data
from one form submission to another, so that, you can, for example,
view a catalogue and add items from different pages to the same order.
There are other ways of doing this, but they either require that all
pages be dynamic (a reasonable constraint for many internal business
applications moved to web browser technology) or an explicit sign on,
so that you can use the user authentication data to track the person.
Tracking users for market research is only barely maintaining state in
the traditional, computer science, sense.
> (so we stop non-cookies browsers at the
> front home page) and we have to rely on
The cost of implementing a non-cookies mode for the catalogue ordering type
of application can be sufficiently expensive in development time and will
greatly increase the load on the server and network (killing response
time) that it may not be commercially viable to implement the site in
any other way. (Requiring user authentication could be done about as
cheaply as cookies, but would probably be seen as intrusive by the users).
This, actually, is an area in which Microsoft Active Pages is a problem.
business applications to browser technology, with ad rotation as a
secondary consideration - you don't need active content if all you want
to do is track users), and it makes them so transparent that many people
don't realise that it is using them. Doing things without cookies is
no more difficult that with conventional CGI, but maintaining state with
cookies in ASP is so much easier. (How to disable cookie generation is
an FAQ on the ASP newsgroup.)
The Unix Apache freeware server is also partly to blame. The
documentation of one version implied that a feature which sent cookies
with everything was needed to use them at all. It has now been renamed
the user tracking feature. A lot of the Lynx support pages suffer from
this problem because CRL use that server - possibly they really are
trying to track users, but if they are they don't understand that you
must also make the page uncacheable!
> PS: I've copied this to my editor at the Linux Gazette -- since
Apache, which is responsible for most sites which send cookies with
absolutely everything, is most likely to be found running on Linux! As I
said this is really user ignorance as to the true nature of cookies,
and, as the latest documentation says, you don't need the automatic
++ Although not really a Lynx issue, some ISPs seem to force either
the home page or all html pages to be uncacheable, on customer virtual
sites. Possible reasons for the home page being uncacheable are ignorance
about the impact of using server side includes to embed a hit count.
But making everything uncacheable suggests that they are probably
trying to collect access statistics on every page. Possible reasons
for this are market research on the users of the site for their own
benefit, production of market research statistics for their customers,
or a belief that accurate hit counts (partly market research) are mare
saleable than fast response times.
As I said above, for the web to scale, cacheing has to increase, and a
large part of HTTP 1.1 is about cacheing, but this conflicts with the
desire for service providers to have accurate marketing data and to
provide a high gimmick content.
; To UNSUBSCRIBE: Send a mail message to address@hidden
; with "unsubscribe lynx-dev" (without the
; quotation marks) on a line by itself.