lynx-dev
[Top][All Lists]
Advanced

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

lynx-dev Invent your own scheme for fun and TABLEs


From: Klaus Weide
Subject: lynx-dev Invent your own scheme for fun and TABLEs
Date: Fri, 11 Dec 1998 10:13:19 -0600 (CST)

Here is an idea for making some kind of TABLE support available
*without* any changes in the lynx code.  Maybe somebody wants to
explore this path further - a project which requires no C knowledge
at all.  It does require a script (or some other external program)
that can parse <TABLE> and related tags in HTML and can do something
useful with them.   IIRC there were several of those around, but I
have never tried any of them.

Did you know that you can define your own URL schemes for lynx, without
changing lynx?  Yes you can.  Try this:

  export xyz_proxy=http://some.server/
  (syntax for un-Bourne shells left as an exercise)

Not that this does not work in lynx.cfg, it has to be set as an
environment variable.

Then start lynx and try to access <URL: xyz:something>.  Lynx will try 
to contact some.server and request url:something from it.

Of course, if the server doesn't know anything about the xyz: scheme,
this doesn't get you much.  But if you can configure the server to do
something with it - possible with apache or even the CERN server - then
things get more interesting.

Assume we define the scheme tableparsedhttp: to mean "like http:, but
with TABLEs parsed (and formatted in some way)".  The pseudo-proxy server
defined by the tableparsedhttp_proxy variable could get the corresponding
http: document, run the hypothetical table-parsing script on it, and
return the result to us.  This could be done with a CGI script on the
server.

Here is how it would be used:  User visits a page with tables.  User is
not happy with lynx's formatting of the document -> decides to invoke
the external table formatting:
   press 'G'
   change the URL now displayed by prefixing it with "tableparsed"
   press RETURN key
(If we name the new scheme "ahttp:" instead of "tableparsedhttp:", this
can be shortend to just four keys: G, ^A, a, RETURN)

What if you don't have your own server to configure and run scripts on,
and nobody lets you use theirs?  If you are not using lynx on Unix, you
are out of luck (It's up to you to get a server/proxy that can do it).
If you are using lynx on Unix, let's try to use a lynxcgi script as our
"proxy":

   tableparsedhttp_proxy=lynxcgi://localhost/mybindir/mytablescript.sh/
   export tableparsedhttp_proxy

Of course LYNXCGI has to be enabled to do this.

Now the task left consists of
   - finding (or writing) a table parsing/formatting script
   - writing mytablescript.sh to
     (a) figure out the URL of the requested document from CGI environment
         variables passed to it.  This will need some experimentation.
     (b) GET the requested http: URL.  This could be done using wget etc.
         or using lynx itself (with -source, or maybe with -mime_header).
     (c) Run table parsing/formatting script on the html text.
     (d) Write CGI headers (Content-type: etc.) and result from (c) to
         stdout.

Depending on how the URL-retrieving program and the table
parsing/formatting script work, (b) (c) (d) could be just one shell pipe,
or could use temporary files.  lynx -mime_header could be used to preserve
(some of?) the real document's HTTP headers.  Or lynx -source could be
used to take advantage of its automatic prepending of a <BASE> tag.
If the table parsing/formatting script does non convert html->html but
html->text/plain, it could still be used (with Content-type: text/plain)
to get a formatted version displayed (but without hyperlinks).
There are lots of possibilities to explore once the basic setup works.
For example, tweaks to make it work for POST form results.

Anyone interested?

   Klaus

reply via email to

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