Tim Rowledge is wildly believed having written:

>> 	Why do you need two places for plugins, src/vm/intplugins and 
>> src/plugins ? Is there any problem if all plugins have a home under 
>> src/plugins ?

> There are two places because there are two kinds of plugins. Those in
src/vm/intplugin will be > glommed in with themain vm to become internal
and those in src/plugins will be elevated to the > glorious heights of
external plugins, there to lead an indepentent life of stardom and moral

> turpitude. Having the two places has the virtue of implicitly encoding
what the code is to be > treated as. Yes, one could indeed encode it
other ways, for example it is undoubtedly possible > that VMMaker could
generate a file listing which plugins are internal and which external,
with > some extra work to read the appropriate directory contents etc.
But it's so easy to see the 
> implied meaning from the directory tree, so why hide it?

	No, VMMaker is not hiding anything. In fact, in doing that,
VMMaker is raising the flag for a good cause. VMMaker can generate
something to be included by the main makefile to designate which of the
plugins are to be internal and which are to be external.

	A plugin isa a plugin isa a plugin...

	All plugins can and should share a common roof for their home.

>> 	Do you have any plan to support slide-able plugins, all exported

>> names are always fully qualified with the name of the plugin and a 
>> little change in the lookup mechanism, dropping 'sqNamedPrimitives.h'

>> ? Of course this only work on platforms with support for shared 
>> modules.

> This is exactly the problem that makes this impossible. Portability is
important and we use 
> our own mechanism for handling lookup with internal plugins precisely
becasue some platforms 
> can't do it otherwise. 

	Then VMMaker simply generate a define, say, NO_SHARED_MODULE,
then the good old faithful mechanism used with 'sqNamedPrimitives.h'
will kick in to support these platforms. According to Andreas, these
platforms are just the barebone ones. 

	No thing is lost, there is only gains. (Now am I talking about a
perpetual machine ;-)

> It's probably faster than most OS versions anyway because it is so 
> specific to our needs rather than general. Certainly we could make the
function names in 
> external plugins use the same naming as those in internal plugins but
I'm not sure there is 
> any actual value in it. I suppose there isn't much cost either, though
it would mean 
> concatentating two strings every time we do a lookup.

	Yes, this make the plugins truly slide-able instead of just
screw-able. ;-)

	The building process is greatly simplified, instead of 'Build
your own VM in 24 hours' it will be 'Build your own VM in a few minutes'
;-)

> Tim

	Cheers,

	PhiHo.