Re: [Jsynthlib-devel] [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1116] trunk/JSynthLib/doc/synths.html

[William Z. <wrz...@po...>]

On Sun, Sep 4, 2011 at 10:45 PM, Joe Emenaker <jo...@em...> wrote:

> Well, I was *also* thinking that, if we're going to have
> dynamically-loadable or downloadable synthdrivers, then there's going to
> need to be some kind of way to interrogate the synthdrivers to ask them
> what they can do. We may be able to get some mileage out of merely
> parsing the classnames and pulling off "BankDriver" off of the end and
> whatnot... and we can also use Java's inspection features to find out
> what each class' superclass is (ie, Driver or BankDriver, etc.).
>
> However, one could argue that the *right* way to do it is to add some
> static identifier methods (like getManufacturer(), getSynthName(),
> getDriverType(), etc.) which would be abstract in Driver or BankDriver
> (so that every synthdriver had to define them). If we decided to do
> this, we should implement it sooner than later, because there will only
> be more drivers in the future.
>

You might look at
ServiceLoader<http://download.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html>.
Granted, Devices aren't services, but this seems to implement some of the
mechanism we want.  Not all of it; I don't think it will load jar files
after the app has started up.

However, the really right way to do it is with a config file that allows us
to examine available drivers without actually loading the classes.  This
conserves memory, and also holds down startup time.  This isn't a problem
for us right now, but some professional apps have plugin synths that are
incredibly huge.  If by some fluke JSynthLib becomes popular, we may need
this.

Googling 'round the net, I also found a toy system:
   http://sourceforge.net/projects/javasps/
A more powerful system:
   http://jpf.sourceforge.net/
And extreme overkill:
   http://en.wikipedia.org/wiki/OSGi

-Bill Zwicky