[gmpi] Re: Reqs draft

  • From: eric <dilvie@xxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Sun, 09 Nov 2003 14:09:39 -0700



Tim Hockin wrote:

On Sun, Nov 09, 2003 at 10:08:24AM +0100, Vincent Burel wrote:


Disagree totally. I know you are very windows centric and I am very
non-windows centric. Reasons below..


This concept can be implemented everywhere , The registry can be a special
file somewhere, or a database. CLSID is good because this defines a uniq
Ident for a plug-in ... don't understand how you can Disagree Totally....



OK, so when you install a plugin, you need to probe it and install
meta-data.  Why not just do that in your host, and leave it at that?  Save
it once, and that's all you need.

I don't know about you, but I'd like a very simple, lightweight utility that will let me manage my plugins and my hosts. A simple way to select which plugins show up in which hosts would be great. Plugins/hosts often have compatability bugs, some plugins don't make sense in certain hosts, etc...

IMO, supporting this functionality in a simple way should be a requirement, and if it isn't in the GMPI spec, I'm going to make sure the requirements are met for OMS anyway... and other developers might do the same thing differently... it might as well be done in a standardized way. We have the opportunity right now to make things a little easier, or a little harder, depending on how we decide to implement plugin discovery. My idea is fairly simple:

1) plugin directory, specified by an environment variable (this can be in ~/gmpi for unix users)
2) xml file for each host with a list of plugins the host should not attempt to load.. preferably, this should be kept in the plugin location so that third party managers can be used.
3) for each plugin, a simple xml file with the plugin description, including capabilities (what it implements). I would prefer it if this were kept inside a .jar file or something similar along with the plugin binary and any supporting files (such as sample sets).

Why keep this info OUTSIDE the plugin? It's part of the plugin. The only
thing is does is add an chance to get out of sync..


Because , the host MUST be able to get a plug-in list with further
information without loading DLL and without instantiate plug-in object.
(question of speed, reliability, and avoiding buggs)



Loading a dll is pretty lightweight.  YOu need to be able to probe without
instantiation.  Speed: It's O(1) - you do it when you add a new plugin,
only.  Reliability - huh?  Bugs - If there are bugs, it will show up sooner
or later.  I prefer sooner, honestly.

Loading a dll isn't always lightweight. Some developers don't know what they're doing. I agree that those services should be supplied by a dll, but I don't agree that people should have to load a dll to learn something about the plugin. IMO, they should be able to learn something about a plugin just by browsing an XML file. If GMPI doesn't do it, OMS will do it anyway, and we're likely to end up with competing ways to implement the requirement.

The fact that it isn't a requirement for *everybody* doesn't mean it shouldn't be a GMPI requirement.

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