[gmpi] Re: Reqs draft
- From: "Angus F. Hewlett" <amulet@xxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 11 Nov 2003 08:57:57 -0500 (EST)
On Tue, 11 Nov 2003, Paul Davis wrote:
> >GMPI plugins should be available to the user with the minimum of
> >intervention. In general, a GMPI plugin should be a self-contained
> >filesystem object (exceptions being plugins with large external data
> >files, and that a plugin may reasonably require common support libraries
> >located elsewhere on the system).
> >
> >It must be possible to install and uninstall a self-contained GMPI plugin
> >using only the platform's native file manager.
> i want to say "bravo!" but then a moment of doubt crosses my mind. do
> you agree with vincent's claims about the perils of having to load a
> DLL in order to get at the metadata? or do you think its OK to do
> that?
I would strongly prefer not to load libraries, provided we can agree on
what metadata should be made available (bearing in mind that different
hosts may have some variation in data gathering requirements). We have
essentially four options plus one hybrid...
1- folder, which is the most prone to user tampering but equally the
easiest for i/o and access via standard system calls. Do people see user
tampering as a major potential problem? (Mac OS X has a nice compromise
here... it allows folders to be marked as packages, they behave more like
files from the dumb-user point of view, but can be accessed by the
programmer like a regular file..). Easily allows a package to contain
multiple platform binaries. Allows other useful resources to be packaged
internally as files... presets, images, data...
2- tar, jar or zip... still somewhat prone to user tampering, but less so;
behaves like a regular file to the user, reasonably accessible via
standard i/o calls or access libs, but less so than a file. Has same
advantages otherwise as a folder.
3- Binary with embedded metadata readable directly from the file system.
Doesn't require any code to be executed. highly tamperproof but does not
allow xplatform binaries; may present a problem for some build tools or
make builds more complex than otherwise.
4- Binary with metadata readable via a specific entrypoint function.
Requires execution, but allows metadata to be built on the fly.
5- Combination of (1) or (2) with (4). The XML or text metadata has a
special flag saying "This plugin builds its metadata on the fly, please
call the entrypoint". Has the advantages of 1/2 and 4, but adds extra
complexity.
---------------------
My personal preference is 1... I don't think user tampering is likely to
be a major problem, and I don't think plugs need to build metadata on the
fly... wrappers can come with a configuration applet which also helps weed
out "GMPI within FormatX within GMPI" recursive-wrapping issues.
(5) is OK but a bit overcomplex imho; (3) is problematic; (4) to my mind
offers little improvement over existing APIs; (2) would be a good
compromise if ppl feel that user tampering IS a big problem.
Regards,
Angus.
----------------------------------------------------------------------
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
Other related posts:
