proper use of MIME types?

[Matthew D Krajewski]

Hello again.

I tried again to get an mp3 to play - this time using a script instead of
using piping, since Paul mentioned in a previous message ("Announcement:
MIME handling added + other changes") that piping may not work.  However,
this also failed.  :(

Here's the line in konq-embedrc:

[MIME Handlers]
audio/mpeg,audio/mp3,audio-xmp3,.mp3=/usr/bin/mp3_wrapper.sh

and here is the shell script:

#!/bin/sh
TMPFILENAME=tmpfile
echo $1 > $TMPFILENAME
/usr/bin/madplay `sed 's/^file://' $TMPFILENAME`

This just chops off the beginning "file:" on the URL and runs madplay on the
resulting path. (assuming that's how it should be done)

Unfortunately, the file "tmpfile" isn't even created, so it doesn't seem
that this script is actually called at all.

Is this kind of action also unstable in konq/E, or could I be doing
something pathetically wrong?  ( <-- always a possibility ;^)

Thanks for any advice.

- Matt K

P.S.  I realize there isn't a configuration option for MIME type support,
but has anyone noticed any options which help?  (See bottom of message:
"Announcement: MIME handling added + other changes")


----- previous message below ------------

Thanks for the reply, Paul!

Sadly, I wasn't able to get it to work.  I tried the piping solution, and
something seems to happen for a fraction of a second (the "stop" button
becomes active for less than a second), but no sound.  Well, at least it
doesn't load up the mp3 file as text anymore, so I know it's doing something
different...

>> P.S.  If the above assumption is correct, could one run applets by
>>directing
>> the .class file, also in an anchor, to a local JVM?  (I'm assuming that
>> there's still no applet support in Konq/E.)
>
>The main problem is that the dummy implementation of applets doesn't even
>trigger the download of the bytecode or archive file.
>
>The other problem is that servers usually send .class files as
>application/octet-stream or they may be packed in a .jar file.

I see.  Well, at least for local files and anchors in the HTML to .class or
.jar files, you should be able to write a script that loads them with a
local JVM, I'm assuming.

Thanks again.

- Matt Krajewski



----- previous message below ------------

> Hello, all,
>
> Has anyone been able to get an mp3 to play with Konq/E?
>
> I'm under the impression that one can click on an anchors and play a local
> mp3 file if konq-embedrc includes something like the following:
>
> [MIME Handlers]
> application/mp3=@audio/mpeg
> audio/mpeg,audio/mp3,audio-xmp3=/usr/bin/madplay
>
> Is this supposed to run the player madplay with the anchor's href file?
> Right now, it just loads the file as as if it were text.  Maybe there's
> something missing from my anchor?  -> <a href="emacspeak.mp3">Click on
> this.</a>

Use something like:
audio/mpeg,audio/mp3,audio-xmp3,.mp3=/usr/bin/mp3_wrapper

Note the .mp3 which is used for extension matching when the server sends no
MIME type or the protocol does not support it (like file or ftp).

You will need a wrapper script since madplay doesn't know how to play URLs
directly.

Another choice is to use  ...=*/usr/bin/mp3_wrapper  which will pipe the
data into the stdin of the wrapper in which case you need not care about
URLs and protocols - the wrapper can contain just "madplay -"

> But then again, I'm a complete novice when it comes to MIME types, HTML
> design or browser configuration, so I might be completely off track.  If
> someone could give me a clue, it would be much appreciated.  Thanks in
> advance!
>
> - Matt Krajewski
>
> P.S.  If the above assumption is correct, could one run applets by
directing
> the .class file, also in an anchor, to a local JVM?  (I'm assuming that
> there's still no applet support in Konq/E.)

The main problem is that the dummy implementation of applets doesn't even
trigger the download of the bytecode or archive file.

The other problem is that servers usually send .class files as
application/octet-stream or they may be packed in a .jar file.