[gmpi] Re: Instruments done, moving on to "Plugin Files"

From: Tim Hockin <thockin@xxxxxxxxxx>
To: GMPI list <gmpi@xxxxxxxxxxxxx>
Date: Fri, 10 Sep 2004 14:38:28 -0700
Catching up:

>  Req 82:   Plugin binaries must be dynamically loadable in their host
>  environments. This is a platform specific definition, and the GMPI
>  specification must define the formats for supported operating systems.

I want to take the word "binaries" out of there.  I also want to add
"Shared object files (such as .dll or .so files) which contain GMPI
plugins must be differentiable from non-GMPI shared object files".

Objections?

>  Req 83:   Each plugin binary must be capable of containing more than one
>  plugin.

Suggest changing to:

  Each plugin (shared object) file must be capable of containing more
  than one plugin.

>  Req 84:   Plugin files must be bundled into a single file on the
>  filesystem.

This has had a lot of argument, and I think has more or less been shot
down.  Bundling everything into a single file (.jar was suggested) has
nice advantages for signing and making plugins a bit more opaque to users.
The cost comes when the host must extract shared object files to a real
file on the file system to use them.

Does anyone want to make the case for keeping this req?  I like it, but I
can't make a solid argument for it.

Instead of bundles, we can require that an on-disk plugin actually be a
directory containing the plugin shared object(s) and any associated files
(presets, graphics, help files, manual, samples, etc).  This means that
every plugin has a place to call their own.  The path to this directory
could be passed to the plugin during init, such that the plugin can always
reference it's own files from that base.

We can define a "plugin bundle" as 1 or more GMPI shared object files and
all associated files in a single directory.

Objections?  Phrasing suggestions?

>  Req 85:   Installing a GMPI plugin must be possible by simply copying
>  the plugin file to a directory. Nothing more is required. Some plugin
>  vendors may require additional actions for their plugins.


Suggest changing the last line to "Plugin vendors may require extra steps,
such as registration, for their own plugins to be functional".

>  Req 86:   It must be possible for non-privileged users to install
>  plugins for their own use.

Any arguments?

>  Req 87:   Enumerating plugins is done by scanning 1 or more directories
>  for GMPI plugin files. If the plugin file includes metadata, the
>  metadata defines the plugin(s) contained in the plugin file. If the
>  plugin file does not include metadata, the plugin must be probed.

First, we should change "scanning" to "recursively scanning".

There has been some debate on whether external metadata is needed or is
even a good idea.  The archives show concerns with slowness of loading
dlls and crashiness of loading dlls as reasons.

My position (I think) is that metadata belongs in the shared object.
Whether you access the data via open() and read() or you have load and
call a probe entry point is irrelevant.  Probing should NOT be done on
every startup, and I think it is perfectly reasonable to expect a host to
cache the results of a probe.

I also don't see a real justification in the "meta-data licensing" issue.
Some plugins will always have to be probed, such as wrappers.  It must be
made clear that the results of the probe() routine might be embedded in
projects.  I can't fathom that being a real legal problem.

>  Req 88:   Plugin metadata must be available without loading/linking a
>  plugin dll.

This is an extension of the previous.  I don't find much value in it.
Arguments...

>  Req 89:   Plugins may self-categorize into a set of GMPI defined
>  categories

Suggest adding "...via their meta-data"

>  Req 90:   It must be possible to have two plugin files with the same
>  file name in two different directories.

Does this need more expansion?  Or should it be bundled into the "plugin
directory" req?

Tim (hoping to wrap this one up soon)

----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules:  Please stay on topic.  You are responsible for your own
words.  Please respect your fellow subscribers.  Please do not
redistribute anyone else's words without their permission.

Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Follow-Ups:
- [gmpi] Re: Instruments done, moving on to "Plugin Files"
  - From: Paul Davis
[gmpi] Re: Instruments done, moving on to "Plugin Files"

Other related posts:
