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".
So will we discuss "unsafety" or "will we support URL opening directly from the VM" ...
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.
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:
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.
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.
What prevents someone to build his own image with his own plugins? (optionally making these available).
For the specific browser feature, I'd be perfectly happy with OSProcess.
Phil
2012/7/20 Camillo Bruni camillobruni@gmail.com
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:
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.
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.
vm-dev@lists.squeakfoundation.org
-
Camillo Bruni -
phil＠highoctane.be -
Torsten Bergmann