All,

I'll have to preface this comment with "I JUST GOT FFI WORKING" but consider
the potential risk of FFI compared to any other external communication
mechanisms.  

"IF" the image is secured so that no changes can be made to a running image
which I suppose would include calls to FFI <...> (he says not really knowing
how the calls are made or interpreted) then there are benefits to direct
calls.  

First the implementation of the dll wrapper would not be in question only
the direct calls to the OS provided calls would need to be reviewed.  

Second securing the image by removing FFI is too drastic in my opinion.  How
will we get Crystal Reports or any other direct API to work without it?

Third support for external API's are simplified for developers by having the
calls in the image not wrapped in a DLL.  Everything is much more
transparent. 

Forth there is not much difference in terms of risk to the system between
the execution of the DLL function and the FFI call if parameters are passed
in.  Both methods need to have proper handling for error conditions before
the primitive call.  I'm not convinced that error checking is better in a
DLL then in Smalltalk and on the contrary if we make the error checking
harder to apply (by pushing it into the DLL) it is less likely that changes
will be made to prevent the error condition.

Ron Teitelbaum

> From: Bert Freudenberg
> Sent: Tuesday, August 01, 2006 11:20 AM
> 
> Am 01.08.2006 um 07:43 schrieb Andreas Raab:
> 
> > nicolas cellier wrote:
> >
> >> So, the plugin are maybe safer because only a few well experienced
> >> and well behaved programmers dare jump the hurd, in a word because
> >> it is rarely used...
> >
> > Given the amount of plugins and the amount of FFI usage I think
> > plugin usage outnumbers FFI usage by an order of magnitude at least.
> 
> Indeed. Just do a "Smalltalk listLoadedModules" to see which plugins
> you are using *right now*.
> 
> You can think of plugins as an extension of the VM, so in principle
> they can be made as safe as the VM itself is - as long as each
> primitive they provide has one specific function that can be checked
> for inputs and side-effects. This is not the case for the FFI
> primitives.
> 
> - Bert -
> 
>