[gmpi] Re: Reqs draft
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Sun, 9 Nov 2003 16:36:43 -0800
On Sun, Nov 09, 2003 at 04:58:20PM -0700, eric wrote:
> >The thing I DON'T like about storing this stuff in an XML file is that it
> >SHOULD NOT be user editable. It is not user-defined stuff.
> >
> I understand that concern, but is there a good reason not to make it
> user readable? It would be easy enough to include a warning in an XML
> comment telling the user that editing the XML could break things.
That's true, I'll admit. Social problem needs a social answer.
> >load the dll (lightweight, paging in very little)
> >call the probe entry point
> > -- returns all the plugin descriptors (could even be XML!)
> >store the plugin descriptors (could be XML)
> >unload the dll
> >
> >What's so wrong with that?
> >
> Only that plugin management becomes host-centric rather than
Yes. I think that is the way it ought to be, with the exception of...
> user-centric. I don't want to see a scheme that would preclude the use
> of some third-party plugin manager utility that allows a user to sort
> plugins into user-defined categories
... I wouldn't mind some way to categorize plugins once and have that stick.
I do not really see this as a major issue..
> and exclude plugins from loading on
> specific hosts, etc...
I don't see any need for this. Anything that is host-specific is
host-specific. Leave it to the host.
> managers do this by actually copying the plugin libraries right into the
> host plugin directories, with MUCH duplication, and a LOT of versioning
THAT is just dumb. Of course GMPI files should be shared. It would be nice
if there were an easy way for the user to sort plugins. I don't think
plugins should sort themselves, except MAYBE as a hint.
> >And for my own understanding, assuming the plugin author provides an
> >external XML file, how do you handle wrappers? Assume I have a VST->GMPI
> >wrapper plugin. I want to enumerate all the plugins in C:\VSTPlugins as
> >GMPI plugins. As I see it you *need* to run code to probe those.
> >
> Agreed, but does that need to happen EVERY TIME you want to look at the
> wrapper plugin for any reason? An XML file doesn't exclude the
> possibility of actually loading a plugin. It just makes it easy not to
> when it's not needed.
Maybe my idea is not coming across. You probe plugins ONCE. EVER. Well,
ok, you probe them whenever the user asks. If it takes 5 minutes, so be it.
You do it when the user asks, and only when the user asks.
Now, you've just conceded that you need to do at least once. So why do
BOTH? You have to load the dll and run the probe routine and store the
results in order to handle some plugins. Just make that the normal process.
No extra work needed by plugins to provide XML files. No extra work needed
from the host to read the provided XML for some plugins and the probed XML
for other plugins. One simple rule.
To determine what plugins are available, you must probe the dll files. If
you don't want to do this at every startup, you should save the results.
You almost had me, until there was no good answer for wrappers. The only
thing my proposal falls short is that it does not provide a way to sort
plugins such that all hosts see the sort. And I don't think that matters.
Sorting the plugins is an O(1) operation per host. You do it once and it's
done. We should be investigating problems that have BAD characteristics.
ones that exhibit e
conced
----------------------------------------------------------------------
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:
