if a superior interface is available via FFI the system should use it over and above the plugin interface.
For absolute privacy, though, The End To End Argument convinced me it would be better to use image-level Cryptography than an external module via FFI. Too opaque.
OT: Just thinking about this made me wonder whether password-encrypted images would be nice to have. The VM can only launch them when the proper key (or file) is supplied... A corresponding primitve to save the image encrypts with a supplied key. Secure images?
On Tue, Nov 19, 2013 at 6:12 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Nov 19, 2013 at 12:00 PM, Bert Freudenberg bert@freudenbergs.de wrote:
On 19.11.2013, at 12:35, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
this is an important discussion that is taking a religious tone thatwe should strive to avoid.
Let's call it philosophical, "religious" is just flame bait.
There are good arguments for plugins, namely security and encapsulation. There are good arguments for an FFI, namely extensibility and platform compatibility.
Agreed.
[... nice explanation snipped ...]
A number of straw men have been raised against the FFI in this discussion.
No-one has been arguing against FFI in general. We agree an FFI is useful, and a more powerful FFI is better. We just (appear to) disagree on how widely it should be used.
Bert asks "Suppose we add a new VM platform, like a VM running on JavaScript in the browser. Do you really want to re-implement all the C libraries utilized via FFI? Or rather a handful of primitives in your language of choice?". First it is not clear that one *can* implement these primitives taking either approach. If the platform, e.g. JavaScript in a browser, takes the Squeak plugin approach of preventing access to the platform except through a restricted set of facilities, then certain functionality will simply be off-limits, whether one has an FFI or not. Second, reimplementing all the C libraries isn't obligatory. If the platform provides an FFI one simply mates to its FFI and accesses the underlying libraries. If it doesn't then that functionality is off-limits, but that doesn't mean the rest of the system doesn't work.
That's where we disagree. If basic functions in the system depend on FFI, and FFI is not available, then the system *does not work* at all. E.g., there are efforts in other Squeak forks to replace fundamental parts of the system (which currently rely on VM primitives) with FFI calls. That's what I am wary of.
I see your concern but it doesn't worry me. I don't see why the system can't be constructed so that it discovers what services are available. It already does that in a number of circumstances. For example, the menu bar includes a system report if class SystemReporter is loaded. So I can imagine that the socket layer would look for an FFI-based implementation and use it if available, falling back on the plugin interface if absent.
In these days of build and test slaves this kind of layering is straight-forward to manage.
One of the fundamental services of a virtual machine is providing a safe and complete environment for the system to function in. Plugins enrich that environment. But FFI pokes holes into that safe environment, reaching out of the virtual world into the "real" world.
Indeed sometimes that is exactly what you need, namely to better interact with the specific host system you are running on. I'm simply saying that we need to clearly separate this from the base system, which should be as independent of the actual host platform as possible.
Again I see this as a straw-man. Yes, the system should be able to provide something portable and safe, and feature-rich. But it should also be able to provide access to the broader environment if so desired. Further, if a superior interface is available via FFI the system should use it over and above the plugin interface. The JIT does this, but you'd never notice. If sse instructions are available they get used, etc. The system already adapts to the underlying host (file directory separators, etc). Whether the system is independent of the host or heavily dependent on it is a matter of perspective. One perspective is to say that it provides portable abstractions of host facilities. Whether one goes through an FFI or a plugin to provide these abstractions makes little difference. I would agree that we keep the FFI separate from /a/ base system, but not form /all/ base systems. I want support for symbolic links and I don't want to depend on a plugin that can't, because the facilities are too different across platforms, provide a portable abstraction of symbolic links across unix, windows and mac. I want to be able to launch an arbitrary external program and not be limited to a small set of supported programs known by a plugin, etc, etc. These are all valid things to have in a base system, but not valid things to have in e.g. a web plugin.
- Bert -
-- best, Eliot