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

 [ ... trying to keep it moving ... slog slog slog ... ]

>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".

sounds good to me. 

>>  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.

agreed.

>>  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.

its way, way to expensive. i don't know about the windows situation,
but on a posix-like system, this would involve writing the shared
object part of the bundle to a new file before being able to call
dlopen(), since there is no run-time linker call that operates on data
in memory.

>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.

much better. quick pass at wording:

   a plugin is distributed (possibly with other plugins) as part of a
   "bundle" that includes the shared object file(s) corresponding to
   the plugin(s), and any associated data. This data could include
   presets, graphics files, help files, manuals, samples. When
   installed on a target system, all files in the bundle should be
   located in a single directory. The bundle directory may contain
   other nested directories, but these directories should be private -
   a bundle directory should never contain other bundle
   directories. Note: this requires that plugin discovery requires (at
   least) single-level recursive searching through filesystem
   heirarchies.

>>  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".

Agreed.

>>  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 don't agree. its not reasonable to expect hosts to know how to
parse ELF, COFF, a.out or whatever the flavor the month for shared
object files on each platform is. the metadata needs to be placed in a
file with a common format across platforms, thus leaving the handling
of the shared object file to platform-specific calls (such as dlopen()
on posix-ish systems). 

>>  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...

its also not optimal to expect plugins to have to be instantiated or
otherwise "created" in order to discover metadata. any self-respecting
host is going to cache the results on one or more operating
systems. why force that on hosts? just stuff the metadata in some
text-based format, and be done with it.

>>  Req 89:   Plugins may self-categorize into a set of GMPI defined
>>  categories
>
>Suggest adding "...via their meta-data"

Yes.

>>  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?

I don't even understand where this is coming from ...

----------------------------------------------------------------------
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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: