On Thu, Mar 4, 2010 at 9:23 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:

> On 03.03.2010, at 00:42, Ricardo Moran wrote:
> > I might be missing something obvious here, but why is FFI forbidden in
> Etoys? Is it a matter of security?
>
> Yes. One of the advantages of having a Virtual Machine is that you can be
> quite sure what the code running in it can and can not do. It has a pretty
> narrow interface to the "outer system". By allowing FFI that interface
> widens to all the libraries on the system, which means all bets are off.
>
> Additionally, FFI calls are highly platform-specific, whereas Etoys
> projects are supposed to work on any platform.
>

Yes, those are very good reasons for excluding FFI from Etoys. If we write a
plugin to handle the communication with the external libraries we use, would
you reconsider including our work in Etoys? (now that I think of it, we will
probably have some license issues... I will have to check that).
Anyway, I think you can include the Arduino and SqueakNxt projects, they
don't use FFI at all, only the SerialPlugin. Would that be ok?
I must say, I would really love to see our projects included in Etoys!


>
> > Regarding the "generic hardware-interface plugin", I think it would be
> great to have something like that but don't you think the underlying
> platforms are very much incompatible with each other?
>
> That's the point of having plugins - they are an extension of the Virtual
> Machine. Just like the VM itself, they present an abstraction to the code
> inside the image. The actual implementation can differ a lot across
> platforms (and often does) but the image doesn't have to care.
>
> So, that generic plugin would present all its actual hardware to the user
> as a collection of abstract input or output ports. There only need to be a
> few functions:
>
> - get number of available ports (1 to n)
> - get label of a port (just a string to be used in the UI, possibly
> hierarchical)
> - get the kind (input/output) of a port
> - get value range (min/max/step) for a port
> - open a port for actual use
> - read data from an open input port
> - write data to an open output port
> - close a port
>
> If there is hardware that wouldn't fit into that framework it can be
> extended of course, but it seems it could cover a lot, no?
>

Ok, I understand your idea better now. It seems you want something a lot
more low level than what we are doing. But you're right, it would be cool to
have a plugin to handle all that stuff and write the corresponding protocols
on top of that.

Cheers
Richo


>
> - Bert -
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100305/532a9e02/attachment.htm