Media/Device Type Spec???
dave at cridland.net
Thu Aug 19 13:03:25 EEST 2004
On Thu Aug 19 09:47:21 2004, Waldo Bastian wrote:
> On Wednesday 18 August 2004 23:03, Dave Cridland wrote:
> > On Wed Aug 18 17:38:48 2004, Jerry Haltom wrote:
> > > This doesn't seem to be hacking mime to me. It just alters the
> > > general
> > > definition of MIME from "type of data stream" to "type of
> > > Isn't this appropriate?
> > I don't think so, no. I think you're guilty of trying to make
> > everything into a nail.
> > I think a MIME content type describes the nature of the data in a
> > stream, or sequence of octets, if you prefer. That's what it
> > has done.
> KDE has solved this problem by the concept of service-types.
> Instead of using MIME types, you could define the following service
> Note that MIME types are a special kind of service types.
That seems logical, or at the very least, they've a common ancestor.
(A source type, as it were).
Briefly, with Avery, I tossed around the idea of supplying a
"context" alongside a URI, to tell the dispatcher how to treat the
URI, so it'd know to treat an 'http' URI as, say, Subversion (or
XCAP, or DAV, or CalDAV, or whichever other overload is popular this
week.), if possible, but with sane fallbacks.
Oddly enough, while looking for something else, I found a precedent
for this in RFC2425 (text/directory, which is the parent format of
It has a SOURCE type, which has a parameter CONTEXT, which appears to
be intended to do just that. Of course, the example given isn't very
inspiring, being an 'ldap' scheme URI, with a CONTEXT of 'LDAP'.
It occurs to me that there's some similarity between "Yeah, this
looks like a file, but actually it's an audio input device" and "I
know it says it's a web server, but I really mean Subversion". I have
no idea whether this is worth exploring any further - I think it is,
but I don't know if it's likely to be taken up.
(Of course, it's always annoying to find out my original idea was
thought of by someone else at least 6 years ago, but still. :-) )
The upshot of this is that some service types are more specific
versions of others, potentially. How compatible do you think this
concept is with existing usage of KDE's service types?
More information about the xdg