[whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers

mike at mykanjo.co.uk writes:

> "Would the sender of that link necessarily know all the formats the URL
> provides?  Anyway, that's an unrealistic amount of typing -- typically
> round here people just copy and paste a URL into an instant message and
> send it without any surrounding text.
> 
> Whereas without any other information, people will generally open URLs
> in a web browser.  So it'd be faster just to send the URL of the page
> which contains hypertext links to all the formats; at which point we no
> longer care whether those links specify the format in the URL or
> elsewhere."
> 
> - The HTML version of that URL could provide the web page
> representation *and* provide links to all the other content types
> available.  

Indeed it could.  In which case the original claimed advantage of the
recipient of the message being able to open a single URL in one of
several different sorts of user-agents is no longer relevant; the links
could specify the format in the URL and this'll work just fine.

> "What is the point of doing it in HTTP if it's being done in HTML
> anyway?"
> 
> - Nothing is 'done' in HTML, it's a markup language. It's being done
> (at the moment) in the URI.

Sorry; that was what I meant.

> HTTP provides conneg, why would you consciously deny developers the
> opportunity to use it in browsers?

HTML 5 implicitly denies things merely by not providing them.  And it
provides things which are useful.  So the question actually needs to be
asked the other way round: what benefits are there in this being
supported?

> "Not just browsers, as I pointed out.  Also many databases which have
> tables with URL fields would need extra fields adding."
> 
> - I suggested the attribute should be optional, so it would make no
> difference; one would simply avoid using it if it was a big problem.

If my database contains URLs of external websites, then it isn't under
my control as to whether this feature gets used.  If those sites start
using it, then my URLs are no longer sufficient to uniquely identify
what is downloaded, and I need to change my database schema (and
software that uses it) to remedy that.

> "True.  But if the current way of doing it is good enough, there's no
> incentive to change."
> 
> - Define 'enough'..! I don't know why/how you get the authority to
> make that assumption!

I don't, of course!  But then, I never made that claim anyway; I said
_if_ it's good enough.

That is, in order to make this change let's first show that the current
way isn't good enough.

> And before you say it; I'm not assuming any authority myself

Good; the editor has a policy of ignoring appeals to authority!

> "There's little point in making browsers implement extra functionality
> and inventing new mark-up and evangelizing it, only to end up with the
> same functionality we started with; there has to be more.  And the
> greater the effort involved, the greater the benefit has to be to make
> it worthwhile."
> 
> - I'll say it again: I'm encouraging you to help browsers become
> better HTTP clients; surely that is high on the agenda here.. right?!

Why?  That's tantamount to an appeal to authority.  Fully supporting
HTTP is a means rather than an end.  Are there situations in which
supporting this particular part of HTTP provides additional benefit to
users?  Or are there many instances of authors tediously coding the same
thing in JavaScript?

Changes should have some real-world benefit, not just bureaucratically
complying with something for the sake of it.

> "Typing that would require my knowing that URL of the PDF also serves
> other formats.
> 
> But, moreover, it requires typing.  Currently the URL can be pasted in,
> the text that the browser copied to the clipboard.  There's no way that
> my browser's 'Copy Link URL' function is going to put on the clipboard
> the exact syntax of wget command-line options.  Having to type that lot
> in massively increases the effort in this task -- even if I can type the
> relevant media type in from the top of my head, without needing to look
> it up."
> 
> - You're using a command line and complaining about having to type too
> much?

Yes.  One reason I find using the command line so efficient is that
there are many features and short-cuts for avoiding having to type
things fully.

> If it mattered that much it would be a 2 second job to write a wrapper
> script of some kind..

That does what?  A wrapper script which somehow contacts my web browser
(running on a different computer) to find out what the media type is of
the link that was most recently copied to the clipboard?

Even if I could work out how to write such a script, why should I have
to?

> wget is a developer tool

Is it?  I thought it was a program for downloading files from the web.

> it's not supposed to be convenient anyway.

Isn't it?  I find it most convenient.

One of the reasons I use it is because its interface is so simple: just
change to the directory I wish to download something to (which is
effectively free, since once the download has finished I'll want a shell
in that directory anyway to work with the downloaded file; and of course
I can enter this without having to type the path in full) then type a
4-letter command name and paste the URL -- very efficient, and for me
involving far less typing or clicking than navigating a graphical 'Save
As' dialogue box.

So wget currently _is_ convenient for me.  And the defence of a change
which will make this significantly less convenient is that it was my
fault for finding it so convenient in the first place?!

> "Or what about if I wanted to mail somebody pointing out a discrepency
> between two versions of the report, and wished to link to both of
> them.  That's tricky if they have the same URL.  Possibly I could do
> it like you have with the wget command-line above, but that requires
> me knowing which browsers my audience use and the precise syntax for
> them."
> 
> - separate versions are separate resources, not separate content
> types. That has nothing to do with conneg..

I was meaning a difference between the HTML version and the PDF version
of the same content (or at least what is supposed to be the same
content) -- how would I link to them?

Smylers

Received on Monday, 17 November 2008 15:23:11 UTC