lynx-dev try again through table munger (and related verbs)

     _________________________________________________________________
   
   [1][Prev][2][Next][3][Index][4][Thread]
   
          lynx-dev try again through table munger (and related verbs)
     _________________________________________________________________
   
     * To: [5]lynx-dev@sig.net
     * Subject: lynx-dev try again through table munger (and related
       verbs)
     * From: [6]asgilman@access.digex.net
     * Date: Fri, 11 Dec 1998 20:00:01 -0500 (EST)
     * Cc: [7]w3c-wai-er-ig@w3.org
     * Reply-To: [8]lynx-dev@sig.net
     * Sender: [9]owner-lynx-dev@sig.net
     _________________________________________________________________
   

Klaus,

No immediate offer to start coding, of course.  But since the WAI
is quite seriously preparing filters and such with the idea that
they could be implemented in an assistive gateway, I would like those
on lynx-dev thinking about how to do the client mods to discuss
the system concept with those thinking about doing the server.

The scenario that WAI-ER is looking at most intently is one where
the user encounters an impenetrable page and says "I want to let
the webmaster hear about this."  The trouble report server would
likely run Bobby on the page, as the user for some further information,
and send off an email to the webmaster at the site where the page
was found.

It would make sense for the server URL to accept the URL of the
offending page in a searchpart, the way the Bobby server does now.

I am hoping for a very simple user interface: the simplest is a
dedicated keystroke, the next is a jump in a jump table that ships
with the standard product.  The point is, the command is "retry
through [middleware server]."  The middleware services could be
defined in lynx.cfg but we need to define a set of parameters or
symbols that could be used so that an URL can be picked out of
the Lynx session memory and included in the HTTP message sent to
the middleware server according to some server-defined form.

This would be already a good thing for the Adobe PDF cracker server.
One can run all one's HTTP through there, but it slows you down.
A more sensible user interface would be that one uses HTTP by
the best available service until one has a PDF document as the
currently selected link in a page, and then the command is invoked
to retrieve that page using the PDF cracker proxy.  This is a one-GET
proxy election.

So we need the equivalent of "d)ocument, l)ink or c)ancel? to
select the URL to send forward, and the equivalent of the print
options menu to select among multiple middleware servqers (PDF,
accessiblity complaint, HTTP trouble diagnosis, ...).  The
"retrieve in background with detached wget process" method could
be included in this menu.

That reminds me we are treading some of the same territory that
can be done with EXTERNAL.  Like it is possible to redirect through
a different proxy by defining an EXTERNAL that calls a separate
copy of lynx with a different lynx.cfg which just happens to define
the proxy you want to go through.

Have I talked myself out of the requirement?

Anyhow, we have some server developers that are really interested
in serving some of the scenarios that you want to serve.

Al

To follow up on what Klaus Weide posted:

>     * Subject: lynx-dev Invent your own scheme for fun and TABLEs
>     * From: Klaus Weide <[6]kweide@tezcat.com>
>     * 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=[9][10]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
>     _________________________________________________________________
>
>     * Prev: [10]Re: lynx-dev RE: "remove the r command"
>     * Next: [11]lynx-dev Removing Bookmarks
>     * Index(es):
>          + [12]Main
>          + [13]Thread
>     _________________________________________________________________
>
>   [14]Lynx mailing list archives
>
>   [15][FLORA HOME] [16][LYNX Home]
t
     _________________________________________________________________
   
     * Prev: [11]Re: lynx-dev Spacing cleanups and nits
     * Next: [12]Re: lynx-dev Hotmail problem
     * Index(es):
          + [13]Main
          + [14]Thread
     _________________________________________________________________
   
   [15]Lynx mailing list archives
   
   [16][FLORA HOME] [17][LYNX Home] 

References

   1. http://www.flora.org/lynx-dev/html/month1298/msg00328.html
   2. http://www.flora.org/lynx-dev/html/month1298/msg00326.html
   3. http://www.flora.org/lynx-dev/html/month1298/index.html#00327
   4. http://www.flora.org/lynx-dev/html/month1298/threads.html#00327
   5. mailto:lynx-dev@sig.net
   6. mailto:asgilman@access.digex.net
   7. mailto:w3c-wai-er-ig@w3.org
   8. mailto:lynx-dev@sig.net
   9. mailto:owner-lynx-dev@sig.net
  10. http://some.server/
  11. http://www.flora.org/lynx-dev/html/month1298/msg00328.html
  12. http://www.flora.org/lynx-dev/html/month1298/msg00326.html
  13. http://www.flora.org/lynx-dev/html/month1298/index.html#00327
  14. http://www.flora.org/lynx-dev/html/month1298/threads.html#00327
  15. http://www.flora.org/lynx-dev/
  16. http://www.flora.org/
  17. http://lynx.browser.org/

Received on Friday, 11 December 1998 20:42:12 UTC