Totally agree

The same level of carefull precondition testing can be achieved in Smalltalk 
and FFI than through plugin.

The major difference is that with FFI, we cannot prevent user to bypass those 
protections and precondition tests.

But if the user also have access to plugin source code, you cannot prevent 
either... The only difference is that it is more difficult to program the 
plugin than FFI, and that is why it is safer in a way... Also, i am not sure 
if we can modify the plugin without restarting the image... Can we?
If not, that's a good point for plugins and security.

If we are lazy, both FFI and plugin implementations will have security holes.
But maybe, code will be corrected faster in a FFI framework.

I have no experience with Squeak plugin, but practiced both user primitives 
and DLLCC in VW. And the latter gave me more flexibility and rapid 
development than the former (except for cross machine portability for which 
good old dirty C preprocessor directives are somehow more efficient).

I would encourage FFI because it does open Squeak on the external world. Of 
course it does scratch the "do it all in Smalltalk" paradigm, but from a 
strategic point of view, opening Squeak is really something needed if you 
want to convince more people to join (think of how easy it is in python to 
call external code).

And sorry, the plugin framework is not simple enough. You have to learn a new 
language that is neither Smalltalk, nor C, you have to go through code 
generation for generating the wrapper function to call your external one, 
then you are on your own to compile the wrapper code and integrate it in the 
image... Rather a long development cycle for Smalltalkers. That is only my 
opinion, and of course, good arguments can make it change.

Nicolas


Le Mardi 01 Août 2006 18:19, Ron Teitelbaum a écrit :
> 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 -