[Vm-dev] Request: VM support for opening browser

Camillo Bruni camillobruni at gmail.com
Fri Jul 20 14:00:15 UTC 2012

On 2012-07-20, at 15:40, Torsten Bergmann wrote:

> Esteban wrote
>>> Well... I also disagree with the argument of safeness. 
>> Exactly, Pharo is inherently "unsafe" so to speak, you can
>> - remove arbitrary methods
>> - add arbitrary new classes
>> - change methods at will
>> - swap any two objects...
> We dont talk about the safeness of the image here! 
> Its always easy to compromise an image with #become: and 
> friends. This is clear as spring water. 
> We talk about how "unsafe" is it to allow Smalltalk
> to harm the external platform. 
> There are two point of views:
> 1. One can include FFI or other mechanisms in image/VM by 
>    default and allow external calling right from Smalltalk.
>    I think this is the way we go for Pharo to align
>    with .NET, Java and friends. 
> 2. Others my see the virtual machine as a clear separator
>    between the image and the platform. 
>    The VM defines the protocol/contract between the image 
>    and the underlying platform to make sure they work 
>    together seamlessly
> Both are valid POV's. The first option can be seen as more "unsafe"
> since you can not control (from VM side) what gets called in 
> the outside platform.
> With option 2 the virtual machine has more control for instance
> when running in a sandbox (browser, the cloud, ...)
> Take netstyle.ch for example: they modified the virtual machine 
> to be more restrictive (only run on specific sockets, writing
> only to relative directories) so they could run images in 
> sandboxed environment on "http://seasidehosting.st".

Well you can always run it in a virtualization environment
and then you have completely shielded of the image

> So will we discuss "unsafety" or "will we support URL opening
> directly from the VM" ...

most probably we will add it, but not as a plugin

> If it is too much work then forget my request. One can circumvent
> it using ConfigurationOfExternalBrowser. But I thought it may
> be helpfull to more controlled/restricted (Option 2) environments 
> too.
> Bye
> T.  

More information about the Vm-dev mailing list