Media/Device Type Spec???
bastian at kde.org
Thu Aug 19 11:47:21 EEST 2004
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.
> What you want to say is that the application handles audio CDs.
> Instead, you appear to be saying the application can handle the
> stream found on audio CDs, so if I copied it somewhere else, or
> mailed it to you, then the app could play it.
> It gets potentially quite awkward, if, say, your device happens to
> really contain a stream. Like /dev/audio, or whatever.
> Why not define something that sits on top of these things? Call it
> "Access Type" or something? If it's a different format, then we can
> even use the same field in the Desktop files to store it. (Like,
> "~audio-cd" or something.)
> Same thing can then be used for URI schemes, we can just bung in
> I don't see why everything should be made to be a MIME type.
KDE has solved this problem by the concept of service-types. Instead of using
MIME types, you could define the following service types:
One would need to qualify a bit better what e.g. a service type of
"device-cd-reader" exactly means of course.
Note that MIME types are a special kind of service types.
KDE service types are defined in $KDEDIR/share/servicetypes
bastian at kde.org | KDE Community World Summit 2004 | bastian at suse.com
bastian at kde.org | 21-29 August, Ludwigsburg, Germany | bastian at suse.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20040819/3a198a7f/attachment.pgp
More information about the xdg