"Bert Freudenberg"<bert at freudenbergs.de> wrote:
> It's mostly to ensure no part of the base system depends on FFI. If it was included by default, people might get the idea to "enhance" Squeak by relying on it. We don't want that.
> 
> The proper Squeak way to expose more of the operating system would be a primitive - what is it that XStreams needs that we don't have yet?

That is interesting. Our inclination on the VW side is to lift things out of the VM into the VI as much as is feasible. Granted, the VM situation is different there. Presumably in Squeak/Pharo it is easier for people to write primitives, which could make a difference. But I wonder how you overcome deployment obstacles, e.g. to deploy a new plugin you need to compile it on all the relevant platforms, get it included in the relevant distribution channels, etc. Does that really scale ?

In my specific case with Xtreams I want to take advantage of OS level cryptographic primitives. These days they are pretty much always present on any reasonably recent platform. They are faster (usually orders of magnitude faster), someone else is responsible for keeping the algorithm portfolio up to date, etc. The other half of my motivation is making sure that an external implementation can be plugged in and demonstrate how to do it. Often you simply have to use specific implementations, either because it has to have particular certification, or be on particular "approved" list or it is backed by hardware support that has to be leveraged (accelerators, hardware security tokens, etc). So in this case I'm trying to use the native BCrypt APIs on Windows and OpenSSL's libcrypto everywhere else (for now). With decent FFI, all I really need to maintain is my set of packages on squeaksource. If done right, it should just work right after loading. I think that's about as easy as it can get. I'm not sure I could take on maintenance of a plugin as easily.

Cheers,

Martin