On Sat, 20 Apr 2002 17:24:11 -0400 [EMAIL PROTECTED] wrote:
> > My 'helper applications' were *not* set up to pass .cgi
> > (which is how that site's "pointer files" have been named).
> > I added .cgi to the appropriate 'helper application' entry.
>
> What is the appropriate helper application and how to you add it?
long Long LONG story !
I believe that the browser, when it fetches a file, looks in some
internal tables to figure out what to do with that file. I believe
that Netscape 'matched' on the file's extension, whereas Mozilla
'matches' on the file's MIME-type as supplied by the server:
- One such table gets built as a result of 'plugins' registering
with the browser. If there is a 'match' within this table, the
file gets passed (while it is still coming in) to that plugin.
(I do not have a RealAudio plugin in my system.)
- Another such table (for 'helper applications') was built by the
user. If there is a 'match' against this table, the browser
passes the file (after it is COMPLETELY read in) to whichever
"executable" has been specified by the user. (This is how my
system is able to "process" various types of files which the
browser does not otherwise handle -- I've manually supplied
'helper application' entries telling the browser which files
(including RealAudio) to pass to which "executables".)
- Files which the browser does not 'match' against externally-
supplied tables are handled according to the internal logic
of the browser. (For instance, Mozilla is ITSELF capable of
displaying .bmp files, and .png files.) I believe that if
Mozilla has no idea of how to handle a specific file, it
defaults to displaying the file on the screen, as though its
contents were text.
- Note that Mozilla/2 has [or at least had] a "shortcut" whereby
a few file-extensions had their files passed off to OS/2. (For
instance, what Mozilla/2 did with .pdf files was to pass them
to an UNSPECIFIED 'helper application' -- meaning that whatever
"executable" had been associated __by OS/2__ with .pdf was what
was launched.)
You ask about adding 'helper application' entries. Go to the
Preferences -> Navigator -> Helper Applications panel, and
(with New Type) add:
Description: RealAudio File
File Extension: RA RAM RM CGI
MIME Type: audio/x-pn-realaudio
Application: e:\app\ram\realplay.cmd (for my system)
Once everything works, clear the "Ask me ..." checkbox.
Note that what gets passed to a 'helper application' is the
complete file as it was fetched. In the case where what is
desired is "streaming data", this file will __only__ contain
the URL for the actual streaming data. It is up to the
"executable" to know how to connect to that URL:
- In the case of RealAudio, the player "knows" how to handle
a file containing an URL. (No "pre-processing" required -
it is fine to just pass the name of the fetched file to the
player.)
- Another of my 'helper application' entries is for Ogg Vorbis.
The player I use needs to be passed the URL itself. So in
__my__ "executable" I have to extract the URL-line from the
fetched file, *then* pass the URL to the player. Matters
are not helped by the fact that streaming .ogg uses the same
MIME-type for the fetched file (containing the actual URL) as
does streaming .mp3 Meaning in __my__ executable I have to
test the extracted URL to see if it is for .ogg or .mp3, so
I can invoke the appropriate player.
It was a gold-letter day for me when Mozilla/2 was enhanced to
allow .cmd files (i.e., 'scripts') as the "executable" specified
in a 'helper application' entry. In my system, I do __not__ run
Mozilla/2 with Odin already set up. So __my__ "executable"
(realplay.cmd) needs to set up the Odin environment, *then* call
the RealAudio player. Before this Mozilla/2 enhancement, I had
not been able to invoke RealPlayer from Mozilla/2.
mikus
