Re: lynx-dev short_url option

[Heather]

> > Weird, I could swear that you and I are -agreeing- here, unusual protocol
> > types are important to preserve.
> 
> It can happen... :)

:D

> > As for "another convention to get used to" ... is going to be that too.
> > No excuse there.
> 
> But "..." is the "natural" way to denote that something has been omitted.
> It is a common convention that I assume most users already know from
> other contexts.

Potentially good point... non-English readers, please pipe in if you folk
use something else for ellipsis / omission mark?

>>>> 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.
> 
> The "current page" in dired mode has a URL that starts with
> "file://localhost", so if URL parts that are common between the current
> page and the current link were omitted you would not see "file://".

might not see "localhost" either.  That'd be fine.

> > > >    port number - now *that*'s important.
> > > Why would it be more important than the hostname or the protocol?
> > If you have a firewall, [...]
> 
> Ok.
> 
> Lynx already discards port specifications durring normal URL parsing
> if the port is the same as the default port for the scheme, so it
> seems this is already dealt with in the most convenient way.
>   
>>>> 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.
[many musings snipped further]
> 
> Yes, you wrote something like that, but you are still assuming that
> talking about "CGI's" makes sense here.  I say it doesn't.

It depends.  If the intent is to attempt to preserve important information
as the mangler compresses the URL, then the generic argument "people have
different opinions about what is important" holds true whether something
is a weird directory structure to plain pages, CGI, one of a zillion kinds 
of server hooks, or trips through converting proxies.

> > >  
> > > http://204.71.206.114/RealMedia/ads/click_lx.ads/www.salonmagazine.com/tech/content.html/274871250/Frame2/SalonShoppingBlowout/summerblowout125.gif/63666535393439643337616134353330
> > I'm sure you'll continue to excuse my lack of eloquence as I try to play
> > devil's advocate.
> All I know that the resource denoted by this URL is likely not realized
> on the server as a direct mapping from a static file.  Beyond that, I
> don't know whether the server uses the Common Gateway Interface, or NSAPI,
> or ISAPI, or Java servlets, or Apache's mod_rewrite, or a homegrown
> mod_push_those_ads_out.so, or three levels of internal proxy redirection,
> or something similar, or Something Completely Different.
>
> How do you know whether http://localhost/showenv is a "CGI URL" or not?
> I'm afraid you have made that term up without a definition.  I would
> not suggest to use it when you write to a webmaster, for example (unless
> perhaps when you really *know* that CGI is being used).  

It's probably another nit to pick, but the typical end user cannot tell if
the back end gadget is a script accepting the parameters that the CGI spec
allows, a module that accepts those same parameters, or some other means 
that is using more than CGI would have allowed.  All they know is by speed,
and by complexity of URL, they often feel they can tell if pages are static
or dynamic.  I've heard them in office halls, and when they think something
is dynamic, they don't say "asp" - they say "CGI" - 

So you would call these all dynamic, and stress over whether to even say
that far... because with enough junk on the page, a static one could take
so long it may seem dynamic.  We'd choose different words to compress this
concept.  Oh well!

(That reminds me in my advocacy notes awhile back I forgot to dig up something
on why shipping people a lot of bits at one time puts your modem and cable
modem clients off, and how many bits "too many" probably is.)

You're correct re writing webmasters though.  Since I cannot tell if they
are merely a lackey, clueful, or not, I tend to stay away from any jargon
entirely until I've gotten a reply back from them.  That also helps me 
determine if they seem friendly or hostile towards the idea of improving
their pages.

> I hope you'll continue to excuse my nitpicking.  I do have the excuse
> for it that it doesn't stray further from realistic things than split
> statuslines and AI-like URL-pattern-recognition, which seems to be
> where you are heading.
> 
>    Klaus

I think our play back and forth over what it should or shouldn't compress
in a URL, is good for short_url's design, and should help create something
that will last many revs.

So you didn't mention what you think of the idea of allowing really long URLs
to spend two lines instead...

* Heather