[gmpi] Re: Reqs draft

  • From: eric <dilvie@xxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Mon, 10 Nov 2003 14:56:34 -0700



Tim Hockin wrote:

On Mon, Nov 10, 2003 at 09:36:00AM -0500, RonKuper@xxxxxxxxxxxx wrote:


In terms of requirements, without going into implementation details, we need
a registration system with the following attributes:
- Avoids versioning conflicts, i.e., plugin version 2 overwrites version 1
and projects which contain version 1 start blowing up.



Is this a requirement of the registration system, or just a best practice?
If developer wants Foo version 2 to supplant Foo version 1, and he names the
files the same and installs to the same place and overwrites v1, isn't that
his choice?  And if it breaks -- his headache?



- Avoids naming conflicts, i.e., 2 plugins by competing vendors called
Reverb.DLL.



Fair enough!

Not a requirement: this could be done using the directory (no registry) method by creating a sub-directory for each developer. ie, acme/foo.jar (I still like the .jar file idea.. but that's an implementation issue ;)

- Allows the user to organize and categorize to suit their needs.



Outside the host?

- Supports "safe" and "friendly" diagnosis/uninstall/reinstall by users and
support personnel.



What does this mean?

I'd like at a minimum to have a standard way to tell hosts which plugins to load or not load -- outside the host.
- if a plugin is causing a host to crash, and the user doesn't know which plugin it is, they should be able to tell the host not to load any plugins and then start adding them back one at a time -- without effecting other hosts
- if it isn't done outside the host, there's no guarantee that a host developer will even try to implement such a feature, and even if hosts do implement the feature, they'll all do it in different ways, which can cause a headache for the user.

Note: implementation EXAMPLE. I don't think this is a concern that must be satisfied via a registry. It could be done with a host configuration file stored in a well-known location. A very simple XML DTD could cover it. It could be one big file listing each host and the plugin config, but I'd prefer it if it was broken down, one file per host, just to avoid the possibility of a syntax error breaking the config for all hosts. If a listed file doesn't exist, perhaps the host can log a warning and ignore it. Reminder: don't debate the implementation example, debate the requirements/justification. We've been getting a little off track lately.

Plugin install/uninstall
Ideally should be a matter of discovering where to install, and copying the file/files to the apropriate place. Removal should be a matter of deleting the file/files. I see no reason to use a registry which may go out of sync. This isn't a requirement, just my personal preference.

--
~
<http://www.dilvie.com/>



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

  1. Home
  2. gmpi
  3. Archive
  4. 11-2003