<br><div class="gmail_quote">On Thu, Mar 4, 2010 at 9:23 AM, Bert Freudenberg <span dir="ltr">&lt;<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>On 03.03.2010, at 00:42, Ricardo Moran wrote:<br>
&gt; I might be missing something obvious here, but why is FFI forbidden in Etoys? Is it a matter of security?<br>
<br>
</div>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 &quot;outer system&quot;. By allowing FFI that interface widens to all the libraries on the system, which means all bets are off.<br>



<br>
Additionally, FFI calls are highly platform-specific, whereas Etoys projects are supposed to work on any platform.<br></blockquote><div><br></div><div>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).</div>


<div>Anyway, I think you can include the Arduino and SqueakNxt projects, they don&#39;t use FFI at all, only the SerialPlugin. Would that be ok?</div><div>I must say, I would really love to see our projects included in Etoys!</div>


<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
&gt; Regarding the &quot;generic hardware-interface plugin&quot;, I think it would be great to have something like that but don&#39;t you think the underlying platforms are very much incompatible with each other?<br>
<br>
</div>That&#39;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&#39;t have to care.<br>



<br>
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:<br>
<br>
- get number of available ports (1 to n)<br>
- get label of a port (just a string to be used in the UI, possibly hierarchical)<br>
- get the kind (input/output) of a port<br>
- get value range (min/max/step) for a port<br>
- open a port for actual use<br>
- read data from an open input port<br>
- write data to an open output port<br>
- close a port<br>
<br>
If there is hardware that wouldn&#39;t fit into that framework it can be extended of course, but it seems it could cover a lot, no?<br></blockquote><div><br></div><div>Ok, I understand your idea better now. It seems you want something a lot more low level than what we are doing. But you&#39;re right, it would be cool to have a plugin to handle all that stuff and write the corresponding protocols on top of that.</div>


<div><br></div><div>Cheers</div><div>Richo</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<font color="#888888"><br>
- Bert -<br>
<br>
<br>
</font></blockquote></div><br>