Re: [Radiator-devel] update

[Patrick M. <pat...@po...>]

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

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?

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

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



Pat Mahoney, no 22