Re: [Radiator-devel] update

[Tim R. <ti...@ga...>]

On Mon, 19 Aug 2002 01:13:08 -0400
Patrick Mahoney <pat...@po...> wrote:
| > The create() function ought to take a module ID so that we can put
| > multiple modules in each plugin library (saves code, memory, disk space,
| > etc.). I'm going to put this into the Windows version, along with a
| > module_enum() function, and see how it works.
| 
| The way it is now, the user requests the instanciation of a plugin via
| its name, a simple string. The Environment object concatenates the
| name with the .so extention (under unix), and finds the 'create'
| method which is assumed to create an instance corresponding to the
| string demanded by the user.
| 
| If you want to allow one .so file to contain several plugins, the
| string submitted by the user cannot be associated with unambiguously
| with one plugin. If we want to do this, i would rather like the plugin
| to register all of its 'create' functions in a stl::map< string ,
| Module*(*)() > kinda data structure, like the doc/dynlib-c++.html
| suggests to do.

OK, what I've got so far:

-- Environment maintains a list of PluginInfo classes, each of which
represents one plugin
-- PluginInfo knows how to load a plugin and ask it what modules it
supports (it should also know how to unload it when the time comes)
-- Environment::create can walk the list of PluginInfo's, asking each
one if it supports the given module. If it does, it calls through the
create pointer that PluginInfo saved
-- If no PluginInfo claims to know about the module, the environment
creates a new PluginInfo and adds it to the list

The Win32 PluginInfo constructor (where the calls to LoadLibrary and
GetProcAddress are located) will try to find the plugin_enum function.
If it does, it calls it to find what modules are supported; if not, it
assumes the plugin supports one module with the same base name as the
DLL.

| Another point... Each plugin is statically linked with the
| environment.lib library. Would it be worth it to make all the plugins
| share one instance of this library?

Yes, it probably would. Options are:
1) Turn the environment into a DLL and have the plugins and UI reference
it
2) Export the environment functionality from the UI

I think (2) sounds best. On Windows the plugin DLL can import from, say,
radiator.exe; I'm not sure of the Posix situation but I think it's
simpler there.

| Plugin ideas... 
| - wave visualizer? it could pipe the data to some graphical
| application...
| - fourier-transformer? it would apply a fourier transform to the data
| and pipe it to some similar graphical app so we can vizualize it in
| the frequency domain...

Hmm... sounds good. I guess the visualisation things need to wait for
the GUI.

| Hrmm... Does windows implement sysv or posix ipcs? :)

Like what? Signals -- yes, but it won't give you any signals other than
what you generate yourself. Pipes -- yes, it's got those.

-- 
Tim Robinson <ti...@ga...>