In the days of web based applications and Smalltalk web frameworks etc. it is often very usefull to open a browser/URL from within Smalltalk. Currently one has to load FFI and ExternalWebBrowser package.
Why not add support into the VM for that. This would allow us:
- provide a link to the homepage of Squeak and Pharo in the about box so people can easy access it right from the image
- to give Seaside/Pier/Iliad/Aida served images a button that opens the browser to the served sites
- server an html based "Help system" from the image and by choosing "Help" from the menu open it
- ...
On Windows it is just a ShellExecute API call - dont know about the other platforms. Is it possible that VM developers agree on a common protocol and provide it in the next VM release cycle?
Any comments?
Thx T.
On Thu, Jul 19, 2012 at 9:16 AM, Torsten Bergmann astares@gmx.de wrote:
In the days of web based applications and Smalltalk web frameworks etc. it is often very usefull to open a browser/URL from within Smalltalk. Currently one has to load FFI and ExternalWebBrowser package.
Why not add support into the VM for that. This would allow us:
provide a link to the homepage of Squeak and Pharo in the about box so people can easy access it right from the image
to give Seaside/Pier/Iliad/Aida served images a button that opens the browser to the served sites
server an html based "Help system" from the image and by choosing "Help" from the menu open it
...
On Windows it is just a ShellExecute API call - dont know about the other platforms. Is it possible that VM developers agree on a common protocol and provide it in the next VM release cycle?
Any comments?
The thing is... why adding it in the vm and not in the image directly via FFI? I mean, you already have support in the vm for that -> FFI plugin (and Native boost in NBCog). And it's abstract enough to do the job...
I think that in the path to 2.0 there is the idea to have NativeBoost/FFI in the core distribution. It's just that there are plenty of things to do before :P.
Thx T.
On 2012-07-19, at 10:18, Guillermo Polito wrote:
On Thu, Jul 19, 2012 at 9:16 AM, Torsten Bergmann astares@gmx.de wrote:
In the days of web based applications and Smalltalk web frameworks etc. it is often very usefull to open a browser/URL from within Smalltalk. Currently one has to load FFI and ExternalWebBrowser package.
Why not add support into the VM for that. This would allow us:
provide a link to the homepage of Squeak and Pharo in the about box so people can easy access it right from the image
to give Seaside/Pier/Iliad/Aida served images a button that opens the browser to the served sites
server an html based "Help system" from the image and by choosing "Help" from the menu open it
...
On Windows it is just a ShellExecute API call - dont know about the other platforms. Is it possible that VM developers agree on a common protocol and provide it in the next VM release cycle?
Any comments?
The thing is... why adding it in the vm and not in the image directly via FFI? I mean, you already have support in the vm for that -> FFI plugin (and Native boost in NBCog). And it's abstract enough to do the job...
I think that in the path to 2.0 there is the idea to have NativeBoost/FFI in the core distribution. It's just that there are plenty of things to do before :P.
Well once we have OSProcess it's a matter of doing: mac: `open http://foo.bar.com/%60 linux: `gnome-open http://foo.bar.com/%60 (gnome-open is not installed by default, so we will need some trickery here) win: according to torsten the same :)
but indeed this feature is horribly missing!!
I will check with marcus today, most probably we will integrate OSProcess into 2.0 by default.
Hi,
I disagree in general with extend vm complexity to add things that can perfectly work in smalltalk or using a FFI package... is OSProcess is not good enough, then lets make it work, but I don't see the necessity for vm support.
problem is that now you have to install OSProcess and/or FFI to have the functionality but in the future, at least for pharo, that will not be the case in an out-of-the-box image :)
cheers, Esteban
On Jul 19, 2012, at 10:18 AM, Guillermo Polito wrote:
On Thu, Jul 19, 2012 at 9:16 AM, Torsten Bergmann astares@gmx.de wrote:
In the days of web based applications and Smalltalk web frameworks etc. it is often very usefull to open a browser/URL from within Smalltalk. Currently one has to load FFI and ExternalWebBrowser package.
Why not add support into the VM for that. This would allow us:
provide a link to the homepage of Squeak and Pharo in the about box so people can easy access it right from the image
to give Seaside/Pier/Iliad/Aida served images a button that opens the browser to the served sites
server an html based "Help system" from the image and by choosing "Help" from the menu open it
...
On Windows it is just a ShellExecute API call - dont know about the other platforms. Is it possible that VM developers agree on a common protocol and provide it in the next VM release cycle?
Any comments?
The thing is... why adding it in the vm and not in the image directly via FFI? I mean, you already have support in the vm for that -> FFI plugin (and Native boost in NBCog). And it's abstract enough to do the job...
I think that in the path to 2.0 there is the idea to have NativeBoost/FFI in the core distribution. It's just that there are plenty of things to do before :P.
Thx T.
On 19.07.2012, at 00:16, Torsten Bergmann wrote:
In the days of web based applications and Smalltalk web frameworks etc. it is often very usefull to open a browser/URL from within Smalltalk. Currently one has to load FFI and ExternalWebBrowser package.
Why not add support into the VM for that.
+1
There is a primitiveOpenURL in the ScratchPlugin. Maybe one more reason to include it?
And -1 to requiring OSProcess or FFI for this basic function.
- Bert -
problem is that we have lots of "this basic function"... OSProcess is the place where it belongs... this basic function and all the others. I don't want to pollute VM with things that can be loaded in different ways. Don't want to require OSProcess? include it in core distribution... don't start to make the vm grow (and maintainability complexity increases even more) just because you don't like to require packages.
Esteban
On Jul 19, 2012, at 6:42 PM, Bert Freudenberg wrote:
On 19.07.2012, at 00:16, Torsten Bergmann wrote:
In the days of web based applications and Smalltalk web frameworks etc. it is often very usefull to open a browser/URL from within Smalltalk. Currently one has to load FFI and ExternalWebBrowser package.
Why not add support into the VM for that.
+1
There is a primitiveOpenURL in the ScratchPlugin. Maybe one more reason to include it?
And -1 to requiring OSProcess or FFI for this basic function.
- Bert -
On 19.07.2012, at 09:51, Esteban Lorenzano wrote:
problem is that we have lots of "this basic function"... OSProcess is the place where it belongs... this basic function and all the others. I don't want to pollute VM with things that can be loaded in different ways. Don't want to require OSProcess? include it in core distribution... don't start to make the vm grow (and maintainability complexity increases even more) just because you don't like to require packages.
Esteban
The purpose of the VM is to provide services to the image, and hide platform differences. A primitive in a plugin is precisely the right way to expose this functionality. Ever heard of capabilities? If I want to give my application the capability to open a web browser, why would I have to allow it executing any program on the system via OSProcess, or call any library function via FFI?
The primitive already exists. Are you opposed to including ScratchPlugin? If so, why?
- Bert -
On Jul 19, 2012, at 6:42 PM, Bert Freudenberg wrote:
On 19.07.2012, at 00:16, Torsten Bergmann wrote:
In the days of web based applications and Smalltalk web frameworks etc. it is often very usefull to open a browser/URL from within Smalltalk. Currently one has to load FFI and ExternalWebBrowser package.
Why not add support into the VM for that.
+1
There is a primitiveOpenURL in the ScratchPlugin. Maybe one more reason to include it?
And -1 to requiring OSProcess or FFI for this basic function.
- Bert -
yes... but problem is "how"... we already has OSProcess plugin to manage that... why add another plugin? why ScratchPlugin is better than OSProcessPlugin?
Esteban
On Jul 19, 2012, at 7:28 PM, Bert Freudenberg wrote:
On 19.07.2012, at 09:51, Esteban Lorenzano wrote:
problem is that we have lots of "this basic function"... OSProcess is the place where it belongs... this basic function and all the others. I don't want to pollute VM with things that can be loaded in different ways. Don't want to require OSProcess? include it in core distribution... don't start to make the vm grow (and maintainability complexity increases even more) just because you don't like to require packages.
Esteban
The purpose of the VM is to provide services to the image, and hide platform differences. A primitive in a plugin is precisely the right way to expose this functionality. Ever heard of capabilities? If I want to give my application the capability to open a web browser, why would I have to allow it executing any program on the system via OSProcess, or call any library function via FFI?
The primitive already exists. Are you opposed to including ScratchPlugin? If so, why?
- Bert -
On Jul 19, 2012, at 6:42 PM, Bert Freudenberg wrote:
On 19.07.2012, at 00:16, Torsten Bergmann wrote:
In the days of web based applications and Smalltalk web frameworks etc. it is often very usefull to open a browser/URL from within Smalltalk. Currently one has to load FFI and ExternalWebBrowser package.
Why not add support into the VM for that.
+1
There is a primitiveOpenURL in the ScratchPlugin. Maybe one more reason to include it?
And -1 to requiring OSProcess or FFI for this basic function.
- Bert -
On 19.07.2012, at 10:45, Esteban Lorenzano wrote:
yes... but problem is "how"... we already has OSProcess plugin to manage that...
The OSProcess plugin does not provide a specific functionality in the VM. It weakens the boundaries of the VM - if the image has to use FFI or OSProcess, then the machine you are programming in Smalltalk is not virtual anymore. Instead, it becomes a "real" machine: you are programming a PC or a Mac or a Linux box or an iPad or an Android phone etc. For some purposes that's exactly what you want. But not in general, and certainly not for something as useful as opening a URL in a browser.
why add another plugin? why ScratchPlugin is better than OSProcessPlugin?
Because it hides the platform differences behind a simple interface. The implementation of primitiveOpenURL is different on Mac, Windows, Unix, iOS, Android, etc. The image does not need to care about that.
- Bert -
On Jul 19, 2012, at 7:28 PM, Bert Freudenberg wrote:
On 19.07.2012, at 09:51, Esteban Lorenzano wrote:
problem is that we have lots of "this basic function"... OSProcess is the place where it belongs... this basic function and all the others. I don't want to pollute VM with things that can be loaded in different ways. Don't want to require OSProcess? include it in core distribution... don't start to make the vm grow (and maintainability complexity increases even more) just because you don't like to require packages.
Esteban
The purpose of the VM is to provide services to the image, and hide platform differences. A primitive in a plugin is precisely the right way to expose this functionality. Ever heard of capabilities? If I want to give my application the capability to open a web browser, why would I have to allow it executing any program on the system via OSProcess, or call any library function via FFI?
The primitive already exists. Are you opposed to including ScratchPlugin? If so, why?
- Bert -
On Jul 19, 2012, at 6:42 PM, Bert Freudenberg wrote:
On 19.07.2012, at 00:16, Torsten Bergmann wrote:
In the days of web based applications and Smalltalk web frameworks etc. it is often very usefull to open a browser/URL from within Smalltalk. Currently one has to load FFI and ExternalWebBrowser package.
Why not add support into the VM for that.
+1
There is a primitiveOpenURL in the ScratchPlugin. Maybe one more reason to include it?
And -1 to requiring OSProcess or FFI for this basic function.
- Bert -
AFAIS, opening an url in an external browser already "weakens the boundaries of the VM" ... nothing that cannot be solved by OSProcess and an strategy to see which command you need to execute. An approach that also allows you to control the parameters you need to open the browser or to configure it's behavior... something that becomes a pain in the VM, and not necessary at all. IMO, what does not need to take care about that is the VM...
Esteban
On Jul 19, 2012, at 8:09 PM, Bert Freudenberg wrote:
On 19.07.2012, at 10:45, Esteban Lorenzano wrote:
yes... but problem is "how"... we already has OSProcess plugin to manage that...
The OSProcess plugin does not provide a specific functionality in the VM. It weakens the boundaries of the VM - if the image has to use FFI or OSProcess, then the machine you are programming in Smalltalk is not virtual anymore. Instead, it becomes a "real" machine: you are programming a PC or a Mac or a Linux box or an iPad or an Android phone etc. For some purposes that's exactly what you want. But not in general, and certainly not for something as useful as opening a URL in a browser.
why add another plugin? why ScratchPlugin is better than OSProcessPlugin?
Because it hides the platform differences behind a simple interface. The implementation of primitiveOpenURL is different on Mac, Windows, Unix, iOS, Android, etc. The image does not need to care about that.
- Bert -
On Jul 19, 2012, at 7:28 PM, Bert Freudenberg wrote:
On 19.07.2012, at 09:51, Esteban Lorenzano wrote:
problem is that we have lots of "this basic function"... OSProcess is the place where it belongs... this basic function and all the others. I don't want to pollute VM with things that can be loaded in different ways. Don't want to require OSProcess? include it in core distribution... don't start to make the vm grow (and maintainability complexity increases even more) just because you don't like to require packages.
Esteban
The purpose of the VM is to provide services to the image, and hide platform differences. A primitive in a plugin is precisely the right way to expose this functionality. Ever heard of capabilities? If I want to give my application the capability to open a web browser, why would I have to allow it executing any program on the system via OSProcess, or call any library function via FFI?
The primitive already exists. Are you opposed to including ScratchPlugin? If so, why?
- Bert -
On Jul 19, 2012, at 6:42 PM, Bert Freudenberg wrote:
On 19.07.2012, at 00:16, Torsten Bergmann wrote:
In the days of web based applications and Smalltalk web frameworks etc. it is often very usefull to open a browser/URL from within Smalltalk. Currently one has to load FFI and ExternalWebBrowser package.
Why not add support into the VM for that.
+1
There is a primitiveOpenURL in the ScratchPlugin. Maybe one more reason to include it?
And -1 to requiring OSProcess or FFI for this basic function.
- Bert -
vm-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Camillo Bruni -
Esteban Lorenzano -
Guillermo Polito -
Torsten Bergmann