[gmpi] Re: Reqs draft
- From: "Michael Gogins" <gogins@xxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Sun, 9 Nov 2003 16:29:33 -0500
If plugins report metadata on load, then, outside the bounds of the
specification, anybody who wants to can write a plugin manager. We need to
know where to draw the line. The simpler this specification is, the sooner
it will have a chance to make an impact.
============================================
Michael Gogins
gogins at pipeline period com
Irreducible Productions
Silence, a language for programming music and sound
Available at http://sourceforge.net/projects/silencevst/
============================================
----- Original Message -----
From: "Tim Hockin" <thockin@xxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Sunday, November 09, 2003 4:10 PM
Subject: [gmpi] Re: Reqs draft
> On Sun, Nov 09, 2003 at 02:09:39PM -0700, eric wrote:
> > >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...
>
> I see no purpose for that. Managing the list of plugins that a host
should
> offer you is the job of the host. Not some external app.
>
> > 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
>
> You're free to do whatever you like with your own projects, of course. If
> not for GMPI, we'd have XAP, by now (maybe :). I chose to realign myself
> with the only project that has a hope for making a serious impact in the
> industry. In order to make GMPI work, we all need to make concessions on
> our preferred ideas.
>
> > 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).
>
> Seeing as I just talked about concessions, I'm willing to accept some sort
> of 'registry' IF AND ONLY IF it is the will of the majority. The registry
> could be some app you run against your plugin package that stores info in
a
> central place, or it could just be XML files packaged with your DLL.
>
> If the majority of people here strongly advocate that, then I'll go along.
> But if they don't YOU will have to go along. Or do your own API which
only
> you will use.
>
> > >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
>
> This is a social problem. Social problems merit social solutions, not
> technical workarounds.
>
> > The fact that it isn't a requirement for *everybody* doesn't mean it
> > shouldn't be a GMPI requirement.
>
> Actually, that's exactly what it means. More or less. GMPI needs to
> encompass the requirements of MOST uses in MOST environments. Not ALL
uses
> in ALL requirements, and surely not MY or YOUR or HIS uses in any given
> environment.
>
> ----------------------------------------------------------------------
> 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
>
----------------------------------------------------------------------
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:
