protocol handling spec?
Dave Cridland
dave at cridland.net
Thu Aug 12 14:42:57 EEST 2004
On Thu Aug 12 00:35:21 2004, Avery Pennarun wrote:
> Now, is MIME-type inode/blockdevice a good idea or a hack? I think
> it's a
> hack, because /dev/dsp *actually* contains audio/basic, and I have
> a MIME
> viewer for that, and it might make some kind of sense to start that
> when I
> click on /dev/dsp. But I really don't know what to do in this
> case. I
> think we're pretty safe to ignore this particular one, since people
> don't
> *actually* navigate into /dev in konqueror or nautilus and try to
> launch
> block devices.
Yes, absolutely agree on all counts - /dev/ is an edge case, of
course. It's an interesting one, though, and I'm a big believer that
if you can find some edge cases and still have them handled in a sane
manner, then this is a very useful thing indeed.
Now note that I'm not arguing that we *should* support devices in
dev, but I do think it's worth examining how they *might* be
supported, to see if there's anything we can reasonably learn.
I don't think there's ever an application you'd want to start by
default for many of the items in /dev/, but there are actions it'd be
reasonable to offer for some of them. The thing is, in this case the
resource itself has been completely ignored, and the MIME type is
purely derived from the filename, without reference to the actual
resource the URI is referencing. In other words, we've broken our
model.
In this case, we know some interesting things - we know that
/dev/dsp, for instance, doesn't 'contain' audio, as such - it's not
as if it's a file which happens to contain an audio file containing
precisely what you're about to say into the microphone. It behaves
like one in certain respects, though, and 'dereferencing' the URI
does indeed produce an audio stream.
But you wouldn't want to blindly open it - you want to know it's not
just any old audio resource.
So while it has a 'file' scheme URI, and the resource definitely has
a MIME type of 'audio/basic', that's where the similarity with a
normal audio file stops. (I'm taking it as read it is audio/basic,
and moreover that reading from it is listening to the microphone
input. I don't know anything about /dev/dsp and sound in general,
though.)
I'm not entirely sure how to deal with this in any way that is useful
elsewhere. One thing that strikes me as a possible solution is to
mark the resource as different - the problem is, it is and it isn't.
Maybe this is another example of some magic 'usage' name, which
indicates that this isn't an ordinary file scheme URI pointing at a
audio/basic resource, but you don't like that idea. (Yet, I'm hoping
to convince you.)
> > The way I see it, some URIs are streamable, some are not. Some
> can be > coerced into behaving like a stream, some cannot at all.
>
> The ones that cannot be coerced into a stream cannot be "viewed" by
> konqueror. Thus the URI handler for those types should launch an
> app
> instead. This is what I've been saying all along.
>
>
Yes, but moreover, this shouldn't ever be done as a side-effect of
trying to get a stream.
Perhaps I'm just really scared of side-effects. Perhaps I'm just
recalling the Security Considerations section of (almost) every URI
RFC.
> > I think it's a mixture. It's a readable stream interface, if >
> available, and apparently what the user wants. It's treating it as
> a > URI container, if available, and if we think that's what the
> user > wants. Finally, it's running some other program to handle it
> if we > think that's what the user wants.
>
> Agreed.
>
>
This, incidentally, is where the problem about user context comes in,
since it's reasonable to try to treat 'http' scheme URIs in all the
above ways. But you have to probe them in order to do so, and that's
a side-effect.
> > It depends on what the user's trying to do. If they tried
> treating > that URI as a file, it's reasonable to say "Sorry, but
> an IMAP server > isn't a file." Or EISDIR, if we were mad enough to
> get this working > on the command line.
>
> Also fine with me. This is far less hacky than http's approach of
> rendering
> directories as HTML documents if they have no index.html.
>
>
Well, that's not HTTP's approach, rather the convention of web
browsers. HTTP offers nothing to do with directories, all URIs it
handles in its base specification are all either streamable resources
or errors. (Errors are, of course, not only human-readable streams,
but also often have useful information and sometimes useful features.
See, for instance, http://www.virginradio.co.uk/cridland by way of a
typical example which happens to show you information about my
brother.)
This of course results in DAV folders which you can look at as if
they were a webpage. Ultimately, it'll result in everything being
viewable as a web page, thanks to the apparent belief of many
otherwise sensible people who believe that everything should travel
on port 80.
> > >That's nice. But I'm not sure I would ever want to send my
> iCalendar
> > >object to a different program depending on the MIME parameters.
> Maybe
> > >I'm wrong.
> > > For iCalendar, probably not. For text/directory, you almost
> certainly > do.
>
> I don't follow. What parameters does text/directory take? Which
> different
> programs would I want to send my text/directory object to,
> depending on
> those parameters?
>
>
Ah, right.
text/directory; profile=vcard
The above is the MIME Type for vCard 3.0. Of course, everyone's using
vCard 2.1, which is usually denoted as the non-standard text/x-vcard,
and isn't quite interoperable, and because Windows can't handle
dispatch of MIME Types by parameters either, then Outlook has stuck
with 2.1, trapping the world in a Redmond-induced timewarp. Shame, as
2.1 happens to be the ugliest format I know of.
But aside from that, there are potentially other text/directory
possibilities. None, I *think*, are defined as yet, but if one were,
you vCard-handling-app might get mighty confused. (Except, of course,
your vCard handler only supports 2.1, most likely.)
In the case of iCalendar, it might be nice to show an invitation with
a different icon to an established calendar entry. Certainly it's
different to a request for free busy information.
> > >Okay then. Well, I think we can agree that *most* people, when
> they see
> > >an http: url, expect it to be treated as a web page. So for
> URIs that
> > >expect to be treated as something else, we can use another handy
> feature
> > >of monikers: nesting.
> > >
> > > svn:http://foo/blah
> >
> > Sorry, not a URI anymore. Therefore I can't copy that, chuck it
> into > an email, and except someone else to be able to do anything
> with it. > (In fact, Subversion uses svn: for something else
> anyway.)
> > > Moreover, that means I can't copy that to my web browser,
> should I > want to. (I quite often do with Subversion URIs, it's a
> convenient > pager interface to see what's in the repository.)
>
> It's not a URI, but it is a moniker, and if I paste it into my web
> browser
> and my web browser knows that all svn: (we can call it something
> else)
> monikers must be passed to the Subversion app for processing however
> Subversion wants to process things, it'll be great.
>
>
No, in fact, I'll bet you a million that my web browser *can't*
handle that, and *doesn't* know. That's a foolish bet to take, of
course. I'll also bet that not all web browsers capable of running on
Linux will ever handle that. Nor will subversion. Moreover, if I
paste a URI into my web-browser, that's because I want to treat it as
a web page, anyway.
Consistency is, I think, an important goal here.
> Can you email it to people? Well, if we standardized the
> processing of the
> svn: (let's rename it) moniker, then yes. If we don't, then you
> can't, but
> you can't really email them http://foo/blah either, unless you also
> tell
> them *to paste that URI directly into subversion*.
>
>
No, we cannot standardize anything outside our remit, which is 'free'
desktops.
We cannot possibly standardize that Windows should follow our lead,
for instance. To do so would require IETF support (which is unlikely
on the face of it for that proposal, since it breaks backwards
compatibility), and moreover it would require the likes of Microsoft
to support it.
I'm afraid we're stuck with the vagueness of what an http URI means.
An 'http' scheme URI I can email to people. I can tell them to use a
Subversion client to open it. That's okay. It'd be *nice* if I could
email a multipart/alternative with a Desktop file that said "Use a
subversion client, failing that a DAV client" somewhere, plus a
Microsoft-style URL shortcut file, plus a text/uri-list, plus a
text/html and text/plain with human-readable directions. But I'm not
desperate for that.
Aside: Subversion's http URIs are a superset of DAV. Subversion's
file URIs don't resolve to a real file, which is annoying, but also
non-standard, hence a SEP.
> Essentially, in this case subversion requests a different interface
> from the
> monikers it's given than a web browser might. Which interface you
> want to
> request is not intrinsically a feature of the URI (I suppose this
> is the
> point you've been making all along). It is, however, a feature of
> the
> application you're in, and if we're talking about standardizing the
> location
> of URI handlers across desktops, I think the application we're
> mostly
> talking about is the file/web browser (which is the point I've been
> trying
> to make all along).
>
>
No, there's anything using the VFS stuff.
And subversion doesn't support our standard. Nor does Lynx, nor does
Mozilla. I very much doubt they ever will. GNOME has at least two
different webbrowsers, and I still find it fascinating that many
people appear to prefer to use Mozilla even so. I know of many people
who use Lynx for most web browsing, as well.
If we're dealing with URIs, we need to deal with URIs. Treat them as
monikers as much as you like, and it's probably a useful method, but
they have to remain URIs.
> So can we agree that:
>
> - we don't need to standardize URI handlers for Subversion,
> because it's
> application-specific.
>
>
Kind of. There's little point in having a cunning API to allow you to
treat an 'http' scheme URI to a subversion repository as a stream,
because it *is* an 'http' scheme URI - the standard handling for
'http' will cope with that just fine.
However, if I drag said URI out of my Subversion client, drop it onto
the desktop, and later launch that URI-shortcut-thing, then I think
it's perfectly reasonable to expect it to open in my Subversion
client.
I hereby curse the cult of port 80 for this mess, of course.
We can do this by storing an extra thing in with the URI shortcut
file thingy, of course. Lack of the thingy might mean 'use the
default', which is always possible anyway. (And if not, it has to be
because another app isn't following the standard, and is hence a SEP)
For desktop files, we could say "Handler=" plus a buch of handler
'types' that we additionally want to use. This'd be doubly nice,
because we could phase out all the myriad of invented, non-standard,
schemes which get used by the likes of Nautilus. (Like 'start-here'
URIs, purely there as a reinterpret_cast<nail>. It could say
file://localhost/[...] "But use a menu handler for preference.")
Freedesktop.org could host a registry for handler types, which we
could use URNs for, or something similar. (So, for instance, a
subversion desktop link might have a Handler looking like
"urn:xdg:uri-handlers:subversion,urn:xdg:uri-handlers:dav", the
additional 'normal webbrowser' being always silently present.)
I agree that this makes it more complex than simply taking a URI and
using it as a moniker. Feel free to curse the cult of port 80 along
with me.
Perhaps what we really need is a moniker, or set of them, which
provides an interface which we can throw URIs at - in other words,
the urn:xdg:uri-handlers:* are the monikers, and the URIs are not.
Again, an implementation detail. We'd also need a method for getting
the default URI handler for a given URI, on the assumption we aren't
always told what to use.
> - standardizing URI handlers (and their APIs) across konqueror,
> nautilus,
> and mozilla would be nice.
>
>
I doubt we'll be able to persuade Mozilla into handling this stuff.
Not for a long while yet, at any rate. We have to co-exist with
applications that don't understand whatever standard we come up with,
anyway.
> - even URIs that can't reasonably be converted to a bitstream
> should be
> able to implement the standard URI handling API, even if
> creating the URI
> handler simply launches some other app and tells you (konqueror,
> nautilus, etc) to go away.
>
Or tells you that's the only way to handle it, and lets you make a
decision based on that. As I say, I'm a great believer in avoiding
side-effects.
> - URIs that *can* be converted to bitstream give a MIME type to
> that
> bitstream, and the MIME type determines the application that
> should be
> used to view/edit/print/etc that URI. Plus, since the object is
> not
> always ideally represented as a bitstream, we should give the
> MIME app
> our URI handler object, not the bitstream itself (if the MIME
> app can
> handle it), and not just the URI string (since we may have
> already had to
> retrieve it once, and we'd rather not do it again).
>
If you're intent on dispatching via MIME type, which has always
struck me as a reinterpret_cast<nail> sort of solution anyway, then
that's very much an implementation detail at best, and probably not
needed at all. Certainly we don't even need to mention it at this
point. The thing I'm most keen on is avoiding any side-effects we
don't absolutely need. If we really want to treat a URI as a stream
in a particular set of circumstances, then obviously retrieving
information (or the stream) is useful. Otherwise, we shouldn't touch
the network unless we *have* to.
Moreover, I don't think we'll ever get to the point where we can
always eliminate applications which don't understand a URI handler
thing, whatever that thing may be.
So we can usually expect to handle, for instance,
http://example.com/a-jpeg-image by downloading it to
/tmp/example.com/a-jpeg-image.jpg, then handing that filename to the
app.
But anyway...
URIs have:
1) A Scheme.
2) A resource.
I think that's actually all that's common about them.
The resource has:
1) A possibly empty set of MIME types it 'naturally' falls into.
2) A method for obtaining a stream in one of these formats.
(Unavailable if not naturally streamable.)
3) A method for generically launching a handler. (Probably based on
the scheme).
4) A method (or interface) which treats the resource as a container.
(Unavailable in most cases?).
5) A method for coercing a stream out of it. (As a last resort - may
return a stream even when the resource reports an empty list, may
just generate an error.)
I've written these roughly in order of preference of trying them,
although to be fair, that order changes depending on context - as in,
what the user is apparently trying to do.
I think it's safe to fold the base resource interface into the URI
interface, since the two are effectively indistinguishable, but I've
left them seperate above.
Next, an application needs to advertise:
1) The schemes it understands, if any. Lack of any schemes to
understand would indicate it only understands bare filenames (or, if
you prefer, local-only 'file' scheme URIs relative to the working
directory.)
2) The kind of URI handler it can be. So Subversion, DAV, webbrowser,
sound recorder (for our /dev/dsp case)
That's all, but there's a gotcha: We need to have, for want of a
better word, macro-expansion in the list of schemes, because there's
wrapper systems (like GNOME's VFS, KDE's kioslaves, etc) which handle
a consistent set of schemes. So an application which supports them
should just say, oh, I dunno, 'urn:xdg:scheme-set:gnome-vfs' or
something, and that gets looked up recursively. And yeah, that'll be
endless fun if/when GNOME and KDE's VFSalikes end up supporting each
other as a subset.
> If we agree on these points, we can move on to the fun part:
> talking about
> pre-existing implementations, like those of nautilus, gnome-vfs,
> netscape,
> mozilla, mailcap, wget, wvstreams, KDE kioslave, FUSE, and how to
> make them
> play nicely together. It could be a very interesting project.
>
>
It means turning the entire lot into stuff that accesses a wide range
of interfaces via a huge bunch of wrappers, I think, if you want
common code.
> (Avery's mind begins contemplating a UniURI or something.)
If you can then present it as a kioslave/gnome-vfs plugin, that'd be
great.
It seems to me we've three things to do here.
1) Nail whether we want to try to 'relaunch subversion' (and similar
tasks).
2) Sort out cross-desktop URI handler application preferences on a
per-scheme basis. (Because it's easy, and can be done quick - it
should end up being more or less a search and replace on the MIME
preference stuff.)
3) Attempt some kind of universal streamable/container URI VFS plugin
thing.
The key would be sorting out the first two - at that point, we can
start to be able to do interesting things like right click on a
desktop file holding a link to a subversion 'http' repository URI,
and select "Open as folder", and be reasonably sure it'll work sanely
no matter what desktop we're using.
Incidentally, I do wonder whether this urn:xdg:uri-handler stuff I'm
hypothesizing is a close analogue - or even the same thing - as the
MIME actions stuff.
You could have urn:xdg:app-capability:stream:hardcopy for
applications capable of printing a particular document type, or
recording a CD from audio, or whatever. Not sure if it's that
generalizable, but urn:xdg:app-capability:stream:view:read-only would
presumably say "Play", "Read", "Show", etc depending on the media
type in the menus, whereas urn:xdg:app-capability:stream:view could
*also* show "Edit", etc. I'm more or less thinking aloud here,
though, and I can't remember what the state of the actions stuff is
right now.
Dave.
More information about the xdg
mailing list