Where a host application chooses to search for OFX plug ins, what binary format they are in and any directory hierarchy is entirely up to it. However, it is strongly recommended that the following scheme be followed.
Plug-ins should be distributed in the following formats, depending on the host operating system....
Each plug-in binary is distributed as a Mac OS X package style directory hierarchy. Note that the there are two distinct meanings of 'bundle', one referring to a binary file format, the other to a directory hierarchy used to distribute software. We are distributing binaries in a bundle package, and in the case of OSX, the binary is a binary bundle. All the binaries must end with
".ofx"
, regardless of the host operating system.
The directory hierarchy is as follows.....
Where...
pluginIdentifier
field in the
OfxPlugin
struct,
Note that not all the above architectures need be supported, only at least one.
This structure is necessary on OS X, but it also gives a nice skeleton to hang all other operating systems from in a single install, as well as a clean place to put resources.
The
Info.plist
is specific to Apple and you should consult the Apple developer's website for more details. It should contain the following keys...
Plug ins are searched for in a variety of locations, both default and user specified. All such directories are examined for plug-in bundles and sub directories are also recursively examined.
A list of directories is supplied in the "OFX_PLUGIN_PATH" environment variable, these are examined, first to last, for plug ins, then the default location is examined.
On Microsoft Windows machines, the plug ins are searched for in,
On Apple OSX machines, the plug ins are searched for in,
On UNIX, Linux and other UNIX like operating systems,
Any bundle or sub-directory name starting with the character '@' is to be ignored. Such directories or bundles must be skipped.
Different versions of the same plug-in may be encountered in multiple locations, in which case, only the greatest minor version of each major version should be taken note of. For example: 3.2, 1.4 and 2.3 would be noted, but not 3.1, 1.3 or 2.0.
If two copies of a plug-in with the same major and minor version are encountered, it can be assumed they are duplicates and all but the first one ignored.
Some hosts may wish to display an icon associated with a plug-in on their interfaces. Any such icon must be in the Portable Network Graphics format (see http://www.libpng.org/) and must contain 32 bits of colour, including an alpha channel. Ideally it should be at least 128x128 pixels.
Host applications should dynamically resize the icon to fit their preferred icon size. The icon should not have it's aspect changed, rather the host should fill with some appropriate colour any blank areas due to aspect mis matches.
Ideally plug-in developers should not render the plug-in's name into the icon, as this may be changed by the resource file, especially for internationalisation purposes. Hosts should thus present the plug-in's name next to the icon in some way.
The icon file must be named as the corresponding
pluginIdentifier
field from the
OfxPlugin
, post pended with '.png' and be placed in the resources sub-directory.
Some plug-ins may supply an externally specified resource file. Typically this is for tasks such as internationalising interfaces, tweaking user interfaces for specific hosts and so on. These are XML files and have DTD associated with the specific API, for example OFX Image Effect DTD is found in
ofx.dtd
.
The xml resource file is installed in the
Resources
sub directory of the bundle hierarchy. It's name will be
NAME.xml
, where name is the base name of the bundle folder and the effect binaries.