Re: long url names

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.
Although it's tempting to launch into a systems debate, I'm going to try to
avoid that with this response, instead, point out what Wistfulee's problem
is and why it comes about while also pointing out where Harold's answer
misses the point.



> At 02:53 02-01-00 , Lady Wistfulee wrote:
> >I recently created a shortcut on my desktop from  the
> >M$ site that was an EXTREMELY long URL...I could not
> >in any way delete it...I kept getting an "invalid filename"
> >type error message when I tried to delete it, I couldn't  [...]
>
> >My query/comment is this: if having such long URLs creates
> >this problem (I am running win 98 with all its doodahs as
> >updated as M$ has offered) why do web
> >designers/masters/whoever is in charge do this?
>
> A URL is the name of a resource. Period. Bang!

Not so. This is where the whole issue gets sidetracked.

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.
While they may "look" the same, functionally they are different. In Win
95/98, the desktop shortcuts are actually a zero length file with the
shortcut's name as the filename. They are stored in a Windows subdirectory.
So, in a Windows environment, the limits on the length of the filename is
also the limits on the length of the shortcut.

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.
(In some Unix flavors, it's a system administration option.)

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.
Since the operating system uses the file system frequently, less text is
significantly better in terms of performance.

Just think what would happen if you save War and Peace as a desktop
shortcut. Every time you then did a Find, the OS scans all of the file names
for the characters you seek. If it has to scan through War and Peace for
that search then, it's going to take a LOT longer.

The file system does a lot of finds, when you do directory listings, when
you try to run a file that's not in the subdirectory you're currently in...

In a Unix environment the impact of this decision to limit file name sizes
can be easily established. If you "grep" a directory full of very large text
files, you'll see a huge performance hit compared with simply listing
(ls -l) the file list.

That difference explains why system designers impose limits in the first
place.

So, what's happening here is that Lady Wistfulee wants to do something
system designers decided to limit. She wants to save a URL as a shortcut,
and the operating system doesn't like that. The preferred way to do this, of
course, would be to bookmark the URL within the browser itself, and that's
how most people would do it.

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

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.

There are two ways to pass a lengthy database parameter, 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 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. Bookmarking something saves the URL, not the http header
string.

So Microsoft -- and many web designers -- use the get method which appends
the query string to the URL. Unfortunately, sometimes, that query string
becomes too long to save as a shortcut; it bumps into the filename limit
imposed by the OS.

Should Microsoft make more space available for longer shortcuts on the
desktop? Perhaps. But allowing for long shortcuts (a shortcut, as you have
discovered actually becomes a file name) will bring operating system
performance degradation. You can't allow longer file names in one place and
not another.

The correct solution is in place -- save the URL in the bookmarks -- which
eliminates the the desktop shortcut.

Why is bookmarks safe and the desktop not? Because bookmarks are saved in a
separate file... and thus can be whatever length they need to be.

Then Harold wrote:
> When a company sells (whether via forcing purchase via bundling or
discrete
> pricing notwithstanding) a browser that can't handle reasonable URLs, then
> it is a defective product.

But this was NOT the issue at all. The question was NOT whether IE could
handle the URL, but rather whether a desktop shortcut could be created with
the URL. These are two separate issues. The desktop shortcut is the function
of the operating system.

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...
>
> One could easily argue extremely bad engineering on Microsoft's case,
> whether you look at if as they use URLs in their Web site that they can't
> even handle in their browser, or the alternative world view that their
> browser can't handle URLs that even their own Web site uses, either view
> suggesting ~don't they even test their bleepin' products?~
>

As a Microsoft-based developer I do not mind Microsoft criticism. But please
take a minute to understand the question and the issue before launching into
the patented Anti-Microsoft tirade. Before any criticism can be valid, it
must be factually accurate. This criticism does not portray the question
accurately, and thus is simply off base. The issue is NOT the URL, it is the
shortcut. If you want to blast the operating system for not being able to
handle longer shortcuts, then that can be debated. But this criticism
misconstrues the whole issue, why it crops up and provides no illumination
toward solving it.

> You might choose to change (perhaps cripple or complicate) your design to
> accommodate flaws and limitations of browsers used by your visitors... and
> it might be good business sense to do so. [conversely, M$ as a monopoly
> often does not have the market pressure to respond to their client needs
in
> ways you might need to do]

Again, this is NOT the issue. The browser is NOT the issue.

> As far as the browser's use of the hack that Microsoft s toy operating
> system calls a file system (or at least tries to use as one), apparent
> crass ignorance (of its inherent limitations) would hardly be bliss. When
I
> saw them doing so long ago, I was befuddled, the limitations being evident
> almost immediately. That M$ is the johnny-come-lately to the Internet is a
> best an excuse for such flawed-design and rush-to-market tactics.

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

So on one hand, here, the argument is that Microsoft shouldn't support its
older standards -- i.e. the MS-DOS file system that's at the core of Windows
95/98; on the other hand, it's also Microsoft's fault for attempting to move
to the Internet.  Either way Microsoft choses, Harold will find something to
criticize.

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

Eric Anderson
Blaine Software
http://www.blainesoft.com

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