At 12:04 02-01-00 , Eric Anderson wrote:
>Harold misunderstands the question, goes off on 
>a wild and possibly fun bash-Microsoft tangent, 
>but fails to address the issue in the first place.

Reviewing your remarks, I see I was actually right on target.

>> A URL is the name of a resource. Period. Bang!
>
>Not so. This is where the whole issue gets sidetracked.

It most certainly is.

>What Lady Wistfulee is lamenting is the fact that the 
>"shortcut" to the URL on the desktop was too long. 

>Programmatically, a shortcut is a pointer to the URL, and 
>thus, there's a huge difference between a URL and the 
>shortcut.

And therein lies the rub... the Redmond Kids attempt to contort something
into something that in frequent every-day situations it is incapable of
becoming.

>So, in a Windows environment, the limits on the 
>length of the filename is also the limits on the length 
>of the shortcut.

Yes, certainly a well-known limitation, and therein the flaw in the design.

>Most desktop operating systems impose some type 
>of limit as too how long a desktop shortcut or filename 
>can be. Even Unix systems sometimes do this.

Yep. Of course such is the case. Clear evidence of the predictable folly of
the ~design~ at issue here.

>There's a reason. Shortcuts/aliases/whatever/filenames 
>you call them are designed to be POINTERS not the 
>resource itself. Without limits, you could conceivably 
>have the full text of War and Peace as a filename or shortcut.

That I could conceivably have the "full text of War and Peace" encoded
within a URL is my business. The deficiency is further that the broken
software implementation not only does not allow for such cases, but does
not even handle typical situations (e.gll. Microsoft's own Web site URLs).

>Since the operating system uses the file system 
>frequently, less text is significantly better in terms 
>of performance.

Further argument, perhaps, of the futility of the implementation. But, as
you pointed out, such have nothing to do with a URL, except that the
software attempts to make such a contortion.


>So, what's happening here is that Lady Wistfulee wants 
>to do something system designers decided to limit. 

Yep. Therein lies the rub. 

>Realistically, I doubt that many people actually 
>make desktop shortcuts out of most URLs.

Yep. Simple solution... just don't use M$-IE. Or whatever these ~shortcut~
critters are that have inspired such infatuation.

>Then Lady Wistfully asked:
> >
>> >Don't we *want* people to bookmark our sites & come back?

>The answer, of course.
>
>Beyond that, if you are doing a complex database query 
>and passing a lot of parameters, the only way you may 
>be able to create that query is to have a lengthy URL.

Yep.

>There are two ways to pass a lengthy database parameter, 

Two ways are in common use, that much is true.

>and including it in the URL (the get method) 
>is about the only way to do so that allows the user
>to bookmark the page. 

If one defines a bookmark as the saving of a URL, then by definition that
is true. Of course if one defines a bookmark as a shortcut that may have a
truncated version of the URL, therein lies the rub.

If one defines a bookmark as the saving of a query, perhaps more general
than a URL, then such restrictions don't apply.  While you'll not likely
see this in the context of M$-IE, it is very likely in other situations.

If you use the post method, which sends the query 
>string via the http header, you pretty much eliminate 
>someone's ability to bookmark the page. 

Nope. That isn't really how the POST method works. See the HTTP 1.1
specification for details.

>Bookmarking something saves the URL, not the 
>http header string.

Again, if you define a bookmark that way, such is the case. Of course, more
than the ~HTTP header string~ would need to be saved, in a more powerful
definition, such as one that might include POST (and possibly other) methods..


>The Harold wrote:
>>Some M$ advocates might well knee-jerk defend
>> the product... well, it is the malice of those who use 
>>URLs that it can't...

I confess amusement with the timely performance on your part. <g>

>This, of course, ignores that the MS-DOS file system is based 
>on the CP/M file system, which predates just about every desktop 
>operating system on the market today. 

Ah, yes, an ~8-bit~ program monitor system ~enhanced~ to run in the
~16-bit~ mode that Windows 95/98 continues to employ to this day.

>(I seriously doubt if very many Apple IIs are still 
>running, and for the sake of arguement, I do not 
>consider Linux to be a viable desktop operating 
>system for most users as yet.)

Sadly, your knowledge of history is evidently lacking.

>> So, for a pragmatic issue, you may want to constrain 
>> your URLs to only the meager subset that brain-dead 
>> browsers such as M$IE can accommodate without
>> acting like a spoiled brat or shooting their user in the 
>> foot. Not is any way because use of a richer set of 
>> possible URLs is in any way bad or
>> inappropriate, but strictly as a pragmatic issue
>
>And again, this was not the problem.

But, wait... isn't that the gist of your argument... that the Redmond Kids
know better than she what constitutes ~reasonable~ URLs, and similarly only
they have the wisdom to decide arbitrarily what URLs can be saved (as
~shortcuts~ or whatever Redmondesque jargon you might bandy about) and
which ones are ~unworthy~. 

Ergo, if the Lady Wistfulee becomes a good microserf, and eschews the
industry standards for URLs, and instead acknowledges the wisdom of the
Redmond Kids, all will be well with the world.

Safe computing,  /Harold
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Harold A. Driscoll                 mailto:Harold(at)Driscoll.Chi.IL.US
#include <std/disclaimer>                 http://Driscoll.Chi.IL.US

• Web Designer Courses
• Off the Shelf Training Courses

HWG hwg-techniques mailing list archives, maintained by Webmasters @ IWA