"phiho.hoang" <phiho.hoang at home.com> is widely believed to have written:

> > It was also discussed a while ago that it would be cleaner and better
> > security-wise to not use dynamic name lookup for the plugin functions but
> > only for the pre-defined functions (setInterp, getName etc.), and have
> > each module advertise a table of all its functions and addresses. The
> > problem is that on various platforms it is not easy to limit the range of
> > exported functions (like, all C runtime functions are accessible). It
> > would also give some level of reflectivity wich is a Good Thing ;-)
> 
>     At least this will split the array of module, function names and the
> array of function pointers into many small ones in each plugin module where
> they belong.
No, I don't think so. Unless one did lookup of each function *at run
time* via modulename->array in module indirections, involving more
lookups and costing more time.


>     In an attempt to make all plugins external, I found it neccessary to
> introduce the PluginProxy structure so that plugin modules can share some
> functionalities and properties.
I think you'll find that 'platform.exports' already handles virtually
all of that.

> 
>     The 'FilePlugin' also needs something from 'SecurityPlugin', and it is
> also equally easy for 'FilePlugin' to get a pointer to the
> 'securityPluginProxy' etc...
It's already trivial to reference a plugin from another plugin.

>     However, I think many people were working really hard for the named
> primitive mechanism. My proposal regarding the name lookup mechanism and the
> PluginProxy is, IMHO, the cheapest way to support truly slide-able(?)
> external plugins from the current design and implementation.
But you still haven't offered any reason we should value this 'slidable'
plugin. I still can't see any benefit at all. 

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
"Bother," said Pooh, as the doctor diagnosed Syphillis.