Re: lynx-dev short_url option

[Heather]

> On Thu, 5 Aug 1999, Heather wrote:
> 
> > >   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.

Weird, I could swear that you and I are -agreeing- here, unusual protocol
types are important to preserve.

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

well, okay, maybe : is not the right seperator.

As for "another convention to get used to" ... is going to be that too.
No excuse there.

> > 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?)

>From the current page is what I was thinking.  Although, it could get real
tiring seeing file:/// in dired mode, too.

> >    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?

If you have a firewall, it could mean you're less likely to succeed in 
reaching it.  And it is very likely to not be usual for its protocol,
otherwise it would not need to be specified, and the typical webmaster
would not then do so.  So its use at all seems atypical, and should be 
preserved.

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

OK, poor terminology on my part.  My story still holds;  if people see that
we are playing games with the URL anyway, they may want CGI's handled in
a special fashion.

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

I did mention this earlier, didn't I, that unfortunately many CGI backends 
take / to look just like regular URLs?  Or perhaps that ended up in trimmings.
Oh well.  That's why the prompt...

I'm sure you'll continue to excuse my lack of eloquence as I try to play
devil's advocate.

>  
> http://204.71.206.114/RealMedia/ads/click_lx.ads/www.salonmagazine.com/tech/content.html/274871250/Frame2/SalonShoppingBlowout/summerblowout125.gif/63666535393439643337616134353330

But of course, this is *not* a non-CGI URL, though it is an excellent example
of one with no ? delimited query part.

I assume that the current patch would be willing to chop branches between
/RealMedia/ and /summerbloqout125.gif/, because (correct me if I'm wrong here)
it considers that fat number on the far tail, and the hostname at the front,
the important parts.

To my human eye, the buried www.?.com, the further ?.html, and the ?.gif 
leap out as important, and the numeric on the end is obviously some sort
of cookie.

>  
> http://llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch.co.uk:80/history.htm

Yes!  This is the kind of URL I was looking for.  I want to know how the
shortcutters propose to handle something like this.  Some of our folks are
using 66 character wide screens (I saw someone mention that width, anyway)
- the hostname alone might wrap, on their screen. Combine with typical -more-
and it will for sure.

(could we compress the -more-?  hmm.)

In the arguments seen so far, a specified portname is important because it
might be weird, the leaf is important because it's the real page, and we're
reluctant to compress the protocol because it's yet another confusing detail
for an unknowing new user to learn.  So, either this does not qualify for 
compression (because there are no branches to chop out) or the hostname 
itself has to be mangled.

To be comprehensive... someone also mentioned asiatic fonts... is this
patch ifdef'd out for CJK mode, or if not, is it multibyte clean??

* Heather