Re: lynx-dev short_url option

[Klaus Weide]

On Thu, 5 Aug 1999, Heather wrote:

> > Hi,
> > 
> > I have been very complicated for myself...  I must stay to
> > think twice.
> > 
> > In message <address@hidden>
> >     Subject: Re: lynx-dev short_url option
> >     Klaus Weide <address@hidden> writes:
> > 
> > > What I meant with "/.../" is not that lynx should make up another
> > > slash, but (if possible) should try to omitt whole path segments,
> > > so that the despayed string ends up having "/.../" instead of
> > > "/whatever/was/omitted/".
> > >
> > > It seems the patch from <address@hidden> tries to do just that
> > > (I have not tested it).
> > 
> > I intended to do so, but not completely.  ;(
> > But before fix that, there remains still something to be
> > clear.  Besides how to display, yes - that is the problem,
> > what is the most relevant part of URL?  We'd better define
> > explicitly the order of them, though the answer depends on
> > your porpose and situation.
> > 
> >     A. communication protocol
> >     B. hostname
> >     C. middle parts of the path
> >     D. the final leaf
> > 
> > I preferred A > D > B > C without thought, however my patch
> > has a bug.  Someone differ of course.  The original idea of
> > short_url is A > B > D > C, isn't it?
> 
> Hmmm.  This makes me think, how can we reduce each of these best, maybe
> seperately.
> 
> A. Yeah, the protocol is nice to know, but frankly, most web URLs are http,
>    and most of the rest are ftp.  (So, it is important if it's a mailto,
>    telnet, https, etc.) 

It may be http most of the time for most people.  All the more important
to make it visible when it differs from that "normal" case.
 
>    Problem is we're wasting 6 or 7 characters
>    on these common forms.  We could easily replace http:// with h: -
>    ftp:// with f: - and https:// with ssl:

Introducing yet another convention that one has to get used to, and that
on top of that looks like DOS drive letters, seems a very bad idea.

> B. Hostname isn't nearly so important if it's on the local site... even if
>    fully spec'd out.  At least to me.  

All the more important to show it when it differs from the "expected"
one.  (i.e. from the local host?  from that of the current page?)

>    And with the prevalence of .com I'm
>    no longer impressed with that part.  (Of course .com and ... you would
>    only gain one character, so it wouldn't be worth it if that's the only
>    part you get to reduce.)
> 
>    port number - now *that*'s important.

Why would it be more important than the hostname or the protocol?

> C. I think this could be split even further... for some folk, it's only
>    important up to the part where they learn it's a CGI script, all the GET
>    data after that is sort of gibberish.

You are introducing confused terminology here: "GET data" and (below) "GET
portion".  Correct is to call it the "query part" of the URL.  The query
part doesn't have any more GET nature than e.g. the path.

[ other musings snipped ]
> Of course here I have focused on CGI, the only contexts I run into that
> drive a URL to such lengths :)  Anyone have any long URL examples which
> are *not* CGIs?

I hope you are aware you cannot really reliably tell anything about CGI-or-not
from looking at an URL (not should you).
 
 
http://204.71.206.114/RealMedia/ads/click_lx.ads/www.salonmagazine.com/tech/content.html/274871250/Frame2/SalonShoppingBlowout/summerblowout125.gif/63666535393439643337616134353330
 
http://llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch.co.uk:80/history.htm


   Klaus