lynx-dev
[Top][All Lists]
Advanced

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

Some issues (was:Re: LYNX-DEV warning: applets flying about)


From: Michael Ritzert
Subject: Some issues (was:Re: LYNX-DEV warning: applets flying about)
Date: Mon, 24 Feb 1997 09:47:29 +0100

   Date: Fri, 21 Feb 1997 10:14:33 -0500
   From: address@hidden (Larry W. Virden, x2487)
   Sender: address@hidden
   Errors-To: address@hidden
   Precedence: bulk
   Reply-To: address@hidden

   > Important for me are the following issues: 
   > 
   > 1. internalisation of menu/response messages (i'll probably
   > be able to contribute here because we plan to use a lynx with a german ui
   > in our institution)

   Currently there is support for Japanese and English in most of the
   output (all of it?), plus native support for displaying pages in various
   languages.  By following the same steps as was followed for the two currently
   supported languages, additional similar languages should be able to be 
   added.  

Thanks.

   > 2. some kind of java (kaffe?) support, maybe javascript too.

   Um - the applet security issues will resurface at this point.

   I wonder if it would be better to investigate a technology for embedding
   safe languages in the page in an embedded generic object sense rather than
   focusing on Java and Javascript, which are frequently less useful to the
   lynx user because of the use for implementing features that are GUI in
   nature.  I know that's not _always_ the case, but it is more frequently
   the case.

We are going to make data base accesses with java.

   Is there a reasonable way that something like a stand alone applet viewer
   could be invoked (if defined) when lynx encounters a page containing Java
   applets?

This would be a solution in the sense of my question, which i even
prefer over a monolithic solution. Lynx is already getting large :-(

   How far down this path do we trod - support for plugins?

Just another name of what is called module in other programs (apache,
linux kernel, fvwm)

   > 3. some kind of table rendering, like in emacs w3.

   I am not familar with what type of table rendering is done there.  Can you
   describe it for us?

It simply formats tables as good as possible with fixed size fonts,
instead of intelligently ignoring these tags.

   > 4. https support (i'd like to access https://www.fastlane.nsf.gov/ with 
lynx)

   It may already available for you.  Read over the info at
   <URL:http://www.crl.com/~subir/lynx/patches.html> and see if it helps.

   > 5. faster toggling between rendered html and source display --- why does
   >    \ start a full reload and not a reload from lynx' local cache which 
should
   >    be fully sufficient?

   because lynx doesn't keep a local cache of the html.  Read over the hundreds
   of answers to this question thru the lynx-dev archives.

Which means that i should run a local http server as a proxy in order
to get the same effect. A note in the readme would be nice.

   Something I am wondering is whether there is a _simple_ way to provide
   a search capablity to all the information that shows up when a user invokes
   the Lynx help.  It would be so nice if I could get a form that allowed me
   to type in a question on the lynx help page and get back relevant answers
   _just_ from the lynx help files, source code, text files, etc.  and not the
   entire world wide web.

Really good idea. But once You have a local proxy server You can do
this easily simple cgi form and an external search engine like ffw or
swish (does someone know of a GPLed engine?).  Just put the URL of the
cgi interface into lynx.cfg. If there is interest, i can provide an
interface to these engines written in C which suits for these two
systems. Such an approach would help to keep lynx relatively small.

Michael

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;

reply via email to

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