Re: lynx-dev short_url option

[Heather]

> 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.)  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:

(idea tangent: might be user friendly to make SSL links dead if we're not
 in SSL enabled lynx.)

   We could ditch the prefix entirely if the subhost name makes it obvious
   e.g www/web/http => http, and ftp => ftp.  But it might be better to be
   consistent instead.

B. Hostname isn't nearly so important if it's on the local site... even if
   fully spec'd out.  At least to me.  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.

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.  For others, the name of the CGI
   may not be so important as what it's being passed.  It's quite unfortunate
   that spotting a CGI is not as easy as looking for ? since many will take
   "fake directories" as their command parameters.

   But I wouldn't mind terribly being able to get a result like

-more- h:maps.yahoo...?...&csz=San+Jose%2C+CA&Get+Map=Get+Map

D. Of course in this I kept the final leaf, where I defined the leaves in
   the GET portion as split by &.

   But another way would be to only preserve the names passed into this
   CGI, and not the values, until it was reduced enough:

-more- h:maps.yahoo.com/py/maps.py?Pyt&addr&csz=San+Jose%2C+CA&Get+Map=Get+Map

   And to some people the CGI parameters might not be important at all:

-more- http://maps.yahoo.com/py/maps.py?...
 
(idea tangent again) It wouldn't be the same patch at all, but how about a
meta-advanced where two lines are spent on URLs which are overlong?  I would
not want to spend more than three (the amount wasted for a novice menu screen)
but it seems better than losing content for some circumstances.

        http://maps.yahoo.com/py/maps.py?Pyt=Tmap&addr=100+Main+Street&;
-more-  csz=San+Jose%2C+CA&Get+Map=Get+Map

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?

* Heather