Re: [Lcd4linux-devel] Re: Dynamic loading (once more ;)

[Xavier V. <xav...@fr...>]

Hi Michael, hi Martin, hi list !

> > If you want to make it look like OOP, you can use "." for a delimiter 
> > (but it may screw up the parser, since "." is already used for string 
> > concatenation).
> Right. A dot would look nice, but will not work. Maybe a ':' ?? (no, 
> impossible, because of the a?b:c)
we could use @, it seems to be very fashion ;) Moreover, it represents
 well the 'namespace' concept.

> > The user must know which functions exist (and most naturally, that would 
> > be documented on a "per plugin" basis, so the user would also know which 
> > plugin the function belongs to). Actually, it might even make the 
> > config-file more clear (since the plugin-name gives the function a 
> > context, so it's easier to understand what's going on). It would 
> > probably even solve the "duplicate function name" problem, since we 
> > could think of each plugin as a name-space. What I'm thinking about here 
> > is this:
So if I understand it all, instead of invoking xmms('filename'), the
user should invoke 'filename@xmms', so that the eval knows it need
plugin_xmms loaded ? Am I right ?

But then, how would the plugin handle this ?
Eval my call the function xmms('filename'), but this may lead to
problems with plugin_proc_stat :/

> It gives us the same results as the "global function to plugin mapping", 
> but easier to implement (no compile-time work necessary), and allows for 
> modules to be used without recompiling all the stuff. It does not 
> require a list of modules to be specified in the config file.
Right, it may be a good solution.

About dynamic loading of plugins, Martin wrote :
> But I'm looking at embedded systems (well, not _quite_ embedded, but at 
> least very limited as far as space goes), where building can be a pain, 
> and always needs to be done on a separate system. So what I like to do 
> is do a "build everything" on my devel box, and then just transfer the 
> plugins/drivers I need on a specific installation. If a new module 
> arrives in the source tree later on (and I need none of the new 
> functionality of lcd4linux), I could simply pop in the new plugin on the 
> embedded box, and be done with it.
I think you would have to pop lcd4linux binary too, or 'unresolved
symbols' may appear (think of hashes, cfg, ... which are evolving quite
rapidly). But, it's right, in this case my fixed-compiletime hash isn't
a good choice.

Bye !
-- 
Xavier VELLO <xav...@fr...>