Media/Device Type Spec???

[Dave Cridland]

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 
> resource".
> > > 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 
> always
> > has done.
> KDE has solved this problem by the concept of service-types. 
> Instead of using MIME types, you could define the following service 
> types:


> 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 
vCard 3.0).

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?

Dave.