Re: Subset display in dir index (was: Auto download...)

rdenny@netcom.com (Robert Denny)
Errors-To: listmaster@www0.cern.ch
Date: Sun, 29 May 1994 18:49:10 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <199405291646.JAA18993@netcom.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: rdenny@netcom.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: rdenny@netcom.com (Robert Denny)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Subset display in dir index (was: Auto download...)
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: text/plain; charset=US-ASCII
Content-Type: text/plain; charset=US-ASCII
Mime-Version: 1.0
Mime-Version: 1.0
X-Mailer: ELM [version 2.4 PL23]
X-Mailer: ELM [version 2.4 PL23]

> [re: wildcards in server-generated directory listings, "anyone have a 
>  problem?]
> 
> Yes.  It goes against the intended use of URLs because it implies that the
> returned directory will have filenames that are meaningful to the user.
> But maybe that type of URL should be valid. I'd return titles, not the
> directory list.

The CONTENT of the document returned is what has the filenames, not any
URL. So this stays with the notion of opaque URLs, unless you would argue
that putting wildcards in the request url in the first place is not
opaque. 

> I have huge directories of files with filenames that are utterly
> meaningless to the user (news items, hierarchical menus, people and company
> profiles, etc.).  I'd hate to allow users to waste server time grabbing
> huge meaningless directories.  I'm totally against any proposal that would
> require filenames to be meaningful to the user, or even the client, for
> that matter.  They need to optimized for the server and whatever software
> creates and maintains them.

Don't allow the server to "see" these directories. You can do this with
alias control. The concept of server-generated directory listings is very
powerful, and extends the capability of the Web in a truly useful way.

> I'm generating tons of files and filenames automatically.  Twice I tried to
> use meaningful file names (partly because AppleSearch, which I'm using,
> returns filenames), but the complexities of automating that process are
> nasty, especially when you're designing for the least common denominator
> O/S -- DOS, with 8 chars and an extension, or even worse, CompuServe, with
> six chars and an extension!  Further, the HTTP spec rather clearly says
> that URLs aren't meant to be interpreted by users.

The NCSA and CERN HTTP servers support titles, and even automatically
extract the HTML title from HTML documents that appear in a directory. The
file names needn't mean anything. And you _do_ want to know the size before
fetching, right? And the last modified date so you can tell if it has
changed..., and you need to know the filename in order to "address" the
file and get it. I suppose you could hide the filename, omitting it from
the directory listing, and only show the title, size and last-mod date. But
I think the file name is useful. 

> Here's an alternative idea -- instead of returning a directory in response
> to a URL like that, return a list of document <title>s as HREFs!  Hmm, I
> like that one...  It would save the server from having to respond to a
> series of HEAD instructions from a robot, among other things.  Adding file
> sizes might be nice, too.

The Windows NCSA server already supports the ability to have HREFs in the
titles. It also displays the size and last mod date. BUT... the intent of
permitting HREFs in the title is to permit annotations, to allow the title
to link to an expanded description for the file, not to hide the file name.
I don't see the benefit in hiding the file name in a directory listing.

The above discussion doesn't directly address the issue of using wildcards
in file names for server generated directory listings. Instead, it
addresses the issue of server-generated directory listings. It's a fact of
life that files have names, and that people deal with files by their name.
It seems to me that using HTTP/HTML to serve files (without authentication)
is a good idea. It sure gives a friendlier interface than anonymous FTP.

    -- Bob