Andrew,

> Am I correct in presuming that this will all be done "behind the
> scenes," in that the same message
> 
> 	<primitive: 'foo' module: 'bar'>
> 
> would be used to access either?

You are correct.

> That being said, can we be assured that
> the identifier 'foo_bar' will be recognized on every machine, 
> or must we put limits on aggregate length "+1 for the hypen" to 
> cater to the least common denominator machine?

Good point. I didn't even think of it. Does anyone out there know exactly if
there are machines on which dlsym() or similar is limited to less than 255
characters?!

> If you do this, may I suggest that the search path begin with external
> modules, so that even when a fat executable exists, the search will
> first be made to see if a substitute module exists, so that the fat VM
> can be extended simply by adding a new plugin, without having to do
> surgery on the VM executable or a new system install of the thin one?

That's part of the lookup scheme already.

> IMHO, the single best way to address this is to assure, at 
> least, that a plugin directory can be used on all platforms 
> that can support it.  (are there any that can't?)

Dunno. But John and I are planning to add a specific plugin directory to
avoid clashes between plugins in the system default search path.

> It may be time to consider developing tools to facilitate 
> management of plugins, checking versions and the like, so that 
> an individual can readily determine which plugins are available, 
> which are not -- and what versions are present. 
[...]
> To that end, is it perhaps sensible to add reflective capabilities to
> the plugin files, perhaps a uniform, automatically generated routine
> that will return plugin identifier name, names of public functions and
> the version/date of generation information?

And again, that's part of the plan (though not in the short term). You might
even add stuff like what plugins are already built into the VM, what plugins
are currently loaded etc.


  Andreas