Recommended way handling JS objects for Plugins
checks for specific features of plugins fail. There is presently no defined
the information can be provided under the current specification. A typical
symptom of this problem is to be told that a particular plugin is required
by a website, when it is known that the plugin is already installed.
This document is an unofficial addendum to the Plugin Functional
specification. It is intended to provide guidelines for browser and
plugin authors as to a standardised way of providing information about
Within the browsers JS implementation, the Plugins array consists of a
number of MimeType objects. These contain details gleaned from installed
plugins. Plugins can be indexed by number or by name. These exist as :
This object has the properties :
The elements of this object are defined to be '
This describes the name of the plugin. It is the same as that used with a
string index into the plugins array. Under RISC OS, this should be obtained
This gives a single line description of the plugin. It may contain vendor
and version information. See 'Description
file' for its derivation.
The number of MimeTypes supported by this plugin. This will 'probably'
be 1, but agents may group similarly named plugins to create a larger
object (for example if a plugin named 'Bob' was claiming to support
This is usually the name of the code used to execute the plugin. We
don't have the joy of a single executable providing the plugin. We do,
however, know 'how to run' the code. Since the filename provides the
means by which you execute the plugin, our 'how to run' the plugin
provides a similar facility. This isn't actually too useful to any
system because it uses local file naming style, so using the 'how to
run' is not significant. Therefore, this property should be mapped to
the contents of
objects. This MimeType array can be accessed numerically from 0 (for example
The MimeTypes objects describes the MIME types known on the system. It has
the properties :
The above sections cover the bulk of the Plugin-specific objects and data.
Primarily, the missing data from the Plugins object is the description. This
will be provided by the Plugin in a description file. The description file
will allow for a range of other 'meta-data' to be provided about this
plugin, should there be a need to provide this in the future.
An english description of this type. Since we don't have a 'good'
english description of a particular type, I recommend that this be
taken from the textual RISC OS name MimeMap entry of the content type.
That is :
SYS MimeMap_Translate, MMM_TYPE_MIME, mimetype, MMM_TYPE_RISCOS_STRING, description
If no description can be found, it should duplicate the type name itself.
A reference to the plugin object that supports this content type, or
null if none. This is for use in the
navigator.mimeTypes[x] objects and refers to the
plugin object that supports this type.
This is a string of comma separated extensions which can be used on this
content type. In lieu of any way to read the full list, this should be
the value returned from MimeMap with
extension should be made to MimeMap to read all the extensions which map to
this content type.
This is a string containing the content type that this object refers to.
This should be obtained from MimeMap with
<Plugin$About_xxx>.Info will be a
colon separated tag/value pair file, terminated by newline characters. Tags
are case insensitive. Lines starting with a '#' are ignored up to the next
newline. Lines which are empty (newline, newline in the file) are to be
ignored. Tag entries may contain the characters A-Z, a-z, 0-9, _ and - only.
Value entries may contain any UTF-8 encoded strings. Control characters
(0-31) are not allowed. Tags and values may be of unlimited length.
Currently defined tags are :
Any line which is not understood in the Info file should not be faulted, but
should be silently ignored.
The description of this plugin, to supply to the Plugin object's
'description' property. This may contain the vendor name, plugin version
and any other pertinent information. It is recommended that these match
implementations on other systems as closely as possible to allow
presence or absence of such objects.
All other tags are presently reserved.
The 'Info' file will be given the RISC OS type of Text (&fff).
Justin Fletcher can be contacted at
This page is maintained by
Last modified on 19 January, 2013.
This site is copyright
Fletcher. The accuracy of anything on this site is entirely limited
by his belief system and memory at the time of publication - neither of
which should be relied on. The opinions are entirely his, except where he's
changed his mind.
Quotations are copyright their respective authors and whereever possible
attributions have been included.