Stefano Mazzocchi wrote:
>
> > This allows the
> > client to know what it is that it's requesting - surely thats important?
>
> ??? why?
For EXACTLY the same reason you might like to know what the mime-type
is. So you know how to display the thing. And the added value is you
know beforehand whether the browser can handle the content and whether
to present it as an option.
> > I see .../contents.gif, .../contents.html, .../contents.xml,
> > .../contents.php at there is information that is very imformative to me.
>
> To you "site creator" or to you "site user".
Mainly as a user. _I_ know that a php is likely to be dynamic, that
might affect the way I treat that link. I know that if I follow a link
to a contents.wav file I'm unlikely to be presented with an image.
> Maybe for HTML pages it's not obvious but if you do
>
>
>
> then you are able to reuse that URL for "all" instances and all your
> user devices. Think about WAP phones, low graphic users, SVG capable
> clients, TV-sets, etc...
This is indeed the functionality I want! And this is why I would like to
split the suffix off from the filename. But doing so would promote the
suffix to being an individual fragment of a URI breakdown.
> > Mime-headers & stuff only happen post request.
>
> Yes, that's the beauty of it.
OK, You've lost me there. Mime negotiation is more robust at runtime,
but if the suffix was reliable as a content indicator, things are much
more efficient.
A common example - a default directory listing in Apache :-)
I get presented with a bunch of icons that the server has chosen to map
to mime-types which are in turn mapped to suffix.
Without that short-cut, would it be appropriate for MY browser to
request the type of each resource and then choose an appropriate icon?
I realize I'm clouding the issue with client tasks vs server tasks, but
the logic holds. I run a graphical FTP program, it displays remote files
with icons chosen from file suffix, and chooses binary/ascii mode based
on those decisions.
Thanks to the existance of the suffix, I have a better idea about the
content of the file I'm getting. This is why I say the suffix is as
important as any other part of a URI.
> > > If you type
> > > http://www.apache.org/index.html
> > > you do two mistakes, even if the outcome is the same:
> >
> > Yet another reason for me to detest FrontPage [Spawn of the Devil TM]
>
> No, it's a reason to detest closemindness.
Um? I dunno about everyone else, (I can guess) but looking at my
bookmark list I find that over 80% of my links are in just such a
'closeminded' format. That is, I have linked to a page blah.html. Most
link pages in existance are similar. If this approach is so evil... why
are things that way?
However, I am personally advocating being able to refer to documents
sans suffix, So I'll get on that particular bandwagon if neccessary.
> > All of which makes creating a directory for each file and linking to the
> > directory seem more inviting.
>
> You think? Ok, do it for a site with two hundred million accessible URIs
> and come back to me.
I am NOT serious (I was referring to an earlier speculative posting).
It's just that the most straightforward way (I can see) under current
technology to make your way of linking to
> > http://www.amazon.com/books/it/Dante_Alighieri/La_Divina_Commedia/paperback/comments
actually _work_ is to have a file called index.html iside your directory
called ../comments/
OK, you can pull some tricks with URL rewriting, but that makes it
opaque to the client, and prevents the user from knowing what it's truly
accessing.
Currently, you look at an URL with no suffix, and you guess that it's a
link to a section of a site. That is, a directory. Which will in turn
serve it's index page or whatever...
I look at your ../comments example, and that's what I assume.
In a better world (where linking actually is clever enough to do what I
originally posted this thread about) Your example WILL indeed be mapped
to ../comments.*** where *** is your medium of choice. Current clients
do not do this however.
I thought this was a possible application of Xlink. Seems not.
I think (and it appears you do to) that this is a fine direction to be
moving in.
Sorry you disagree that separating the suffix from the filemane is
significant, but glad you think that the filename should be able to
stand on its own. Maybe we're halfway here.
cheers,
.dan.
:=====================:====================:
: Dan Morrison : The Web Limited :
: http://here.is/dan : http://web.co.nz :
: dman@es.co.nz : danm@web.co.nz :
: 04 384 1472 : 04 495 8250 :
: 021 115 7339 : :
:.....................:....................:
: If ignorance is bliss, why aren't more people happy?
:.........................................: