lynx-dev
[Top][All Lists]
Advanced

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

Re: LYNX-DEV Relative URLs, BASE implementation


From: Foteos Macrides
Subject: Re: LYNX-DEV Relative URLs, BASE implementation
Date: Thu, 24 Oct 1996 20:59:02 -0500 (EST)

Klaus Weide <address@hidden> wrote:
>[...]
>There are still some remaining cases which you didn't cover -
>some I would think are bugs (Lynx shouldn't try to eliminate
>/./ out of ?query and #fragment parts - or is that also for 
>compatibility?)
        
        No, if that's happening, it's a bug.  It should simplify
"parameters", because the only one we treat as maybe really a
parameter is ;type=[A, D, or I], but it should stop at a '?'
or '#'.

>                and some are about whether a slash is retained 
>after a final /. or /.. has been eliminated.  The latter could be
>important if further resolutions are based on it... because then
>it is important whether the base URL ends with a slash... but relative
>URLs ending in /. or /.. are probably not a normal thing in HTML pages.

        I don't know.  It could be a bug that never showed up because
that kind of thing would never actually occur in the real world.


>DIRED mode is behaving rather oddly w.r.t ../ paths (and in other ways
>too), but I haven't figured out yet whether that is related.

        I don't know about that either.  There could be discoordination
from when I stopped simplifying absolute paths in HTML.c (but kept the
choices there, in case any problems showed up).


>> To make new HTTP/1.1 stuff really
>> work well, it might be better to use server-like rules and configuation
>> files, and more of the libwww5's code for access regulation and security
>> checks.  
>
>According to the new libwww's architecture, one would do these as
>"Filters".  The Filters could be based on HTRules, or could just be
>any code (that does some stuff and then returns a different code for
>"allowed" or "forbidden").  It would probably be more straightforward 
>to convert the currently existing checks in LYGetFile.c (and further
>down) to the latter form.
>
>But, sure, rules files sounds good.  "Use your existing CERN server
>configuration file for Lynx without changing it." :)

        Right.  But also, if you stick with my current redirection tricks,
you're stuck with handling one URL at a time, in a one-pass manner.  The
problem though, which will take some thinking, is that some of our security
checks in LYGetFile.c are not based only on the URL itself, but also on the
URL of the document from which that link was obtained (e.g, we can disallow
lynxexec or lynxprog URLs based on the URL of the parent document).
 

>> computer. You would want the select()-based threading for many of the
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> features you'd use on a powerful personal computer, and there's no
   ^^^^^^^^
>> way to predict at this point how much performance would be affected.
>
>Maybe I got too used to Lynx, but what are those features?
>This is a serious question.  The scrolling-while-Lynx-is-retrieving-next-file
>comes to mind, but otherwise I cannot come up with much that is seriously
>missing (or that I miss) that wouldn't require a gooey browser anyway.

        When style sheets become commonplace, someday (reportedly
Netscape v4.0 will support them), people will begin to use those in
lieu of, not in addition to, inline styling.  If Lynx doesn't add
support for them, the Lynx displays will become blah again, like those
in v2.3 and v2.4.  We have the model for fetching a MAP from another
location to inline in the current document, but that's rather simple.
For style sheets, we'll need to fetch them and store them to disk, rather
than memory (ideally), and be able to find them again (and delete them
on exit), and analyze them for things we can do on a character cell
terminal, in conjunction with fetching and rending any document.  That's
just one example on why you'd want more of the libwww5's select()-based
threading and caching code available to Lynx.  The more you do, the more
desireable it becames to be able to do it in the background.  But it's
hard to say anything concrete unless you have your hands on the code
and are actually trying out the possiblities.  And you, are presently
the one doing that.

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
;
; 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]