Re: metadatabase

Kristian G. Kvilekval wrote:
> On Tue, 2003-10-14 at 14:32, Andreas Rottmann wrote:
> 
>>I'd even go as far as not loading the metadatabase _plugin_, if the UI
>>(or other code) doesn't use it. I guess however, that we would
>>eventually need a real plugin manager for that.
> 
> 
> I think we've had this conversation before.. but
> how about a rehash:
> 
> 1. Current plugin system loads everything all the time (blech)
>     and should be redone.
> 
> 2. A new plugin system should load only the needed plugins possible on  
>    demand.  (jeesh...almost like a shared library)
> 
> 3. New Plugins need to support C++ , have versions checking, etc
>    
> 4. Several plugins now have internal code that only tests if the plugin
>    is applicable to the call (true for metadata plugins).   Does the    
>    plugin manager need some sort or rule or test case to determine
>    which plugins should be loaded or should this be left to the
>    plugin user?  If the second option is correct, then how does
>    the plugin user know which plugins to load (back to case 1).
> 
> I would like to see a c++ plugin manager
> that operates using autoload functionality maybe using 
> delegation.    Something like a really smart pointer 
> that when used in call automatically loads the plugin
> (if not already loaded) and forwards the call.
> 
> Similarly,  it would nice to have some plugin code outside
> the plugin for rule testing..
> 
> Something like 
> InfraredPlugin.ui : if (infrared library available) 
>                       autoload (InfraredPlugin.in)
> 
> In order to keep down the errors we see when loading plugins.
>    


My player in development uses a series of polymorphic objects to handle 
things.  Right now i have it setup to create new objects hardcoded 
(non-plugin) but the functionality is there. Basically the player will 
scan a directory on load given a path in the config file, it looks for 
some text strings regarding subsystem, type, and some info on when the 
player is to use it.  Not all plugins are going to be able to be 
completely automatic.  The options screen and all that can by 
dynamically generated to allow the user to enable or disable any of the 
non-automatic plugins.  The automatic ones will be input plugins and 
decoders.  The subsystems know when to want a certain plugin, now the 
problem is making than plugin available.  Now once the right plugin you 
want is loaded, you have to create an object of that plugin to actually 
use.  Now the plugin is compiled against the same base object header 
than zinf is.  this allows the plugin to be based off the same virtual 
class.  Now we can't create an object of a type we dont hardcode in the 
subsystem and hardcoding is maintainance, so we have a pointer to the 
virtual class and upon loading the plugin we've determined we need, we 
execute a standard start function present in all the plugins and send 
the pointer to the "virtual object" to that function.  The plugin thet 
creates a new instance of itself setting the pointer that was sent to it 
to it's own base object and then returns. Allowing the player to now 
access the plugin through the base pointer as one would normally do with 
a polymorphic object.

all the plugins to a specific subsystem should have the exact same 
interface and give and accept exactly the same thing.  No more will the 
mp3 decoder plugin output a different amount of max samples per request 
than the vorbis one. Etc etc. This is how i'm doing my player anyway. 
I go and take the time to make as far as the player is concerned, all 
the plugins look the same.

Like, once the plugins have been scanned and, in my case an info object 
is filled with the corresponding data, say the decoder subsystem does 
something like this once it's determined the type of the stream trying 
to be decoded (This of course requires either hardcoded values or your 
magic mime types file to be up to date with the type of stream you're 
accessing, i like libmagic)

for(some iterator of vector list plugins; iterator->type != TypeNeeded; 
iterator++){
	if(iterator == vector.end()){ return("Decoder for type "+TypeNeeded+" 
Not found");
}
iterator.start(Decoder);
Decoder now points to the Decoder base object of the plugin object which 
just new'd itself.




Plugins which add features and what not do so via all the dynamically 
generated menus and such. Current zinf's ui is all static, and i'm not 
talking about using some crappy ide and script the gui, just that the 
UI's preferences and what not is generated by reading vectors and maps 
and what not.  So even the api is the same for all plugins of a given 
subsystem, they need not only provide a given set of features.  As long 
as they adhere to the api rules, they can do whatever they want.



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php