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

[Nicolas Cellier]

For me, it's not about safety.
It's about mirroring outside word complexity in the image, including
the includes files when it comes to FFI.
Even the simpler case of shells is boring. What is the OS-universal
command to open a web browser? Does it take user preference into
account ? Shall we strip some environment variables when we launch a
64bit app from a 32bit one?

How do ruby/python/java/... open an URL?

The uncontested advantage of in-image code is that you can
change-evaluate it in fast loops.
The second advantage is simpler distribution of code (rather than
VMMaker sources + pre-compiled plugin binaries). Though, plugins
should be pluggable.

But what do you gain about factoring and maintaining code working for
all OS/versions? How do you avoid hardcoding machine specific stuff
(paths, executable names etc...)? You have to plug into rather than
re-program existing system capabilities, so you have to reify these
capabilities and all query/configuration services. In worst cases, if
you have to use FFI, it can take the form of preprocessor directives,
you know the kind of boring stuff configure or cmake, try to
address...

Opening an URL is a very simple test case though, so I'd say Pharo
shoud experiment and recreate an in-image mirror of the plugin (I mean
with same capabilities) using OSProcess shells. It will bring more
feedback before we can vote.

Nicolas

2012/7/20 Luc Fabresse <luc.fabresse at gmail.com>:
>
>
> 2012/7/20 Esteban Lorenzano <estebanlm at gmail.com>
>>
>>
>> Well... I also disagree with the argument of safeness.
>>
>> For me, saying that is like saying a mennonite community is safer just because they are isolated. They are not. And in any case, the price payed for that isolation is to stay in the 18th century...
>> I think putting this solution in vm is a poor solution, that prevents adaptation in time... just like a mennonite community, btw :)
>>
>> Frankly... most important question about having it as a plugin is "who will maintain it?"... because problem is not adding a plugin, problem is keep it in time, and match changing outside technologies.
>
>
> +1 to use FFI
> This time, we will add a plugin for URL, next time we will add another one for XXX, and YYYY.
> Esteban is right, adding more and more plugins is not the right thing to do IMHO since fewer people can maintain it compared to image side code.
> Moreover, we must interact easily/fastly with existing world (OS, libraries, ...).
>
> For the subscription of the VM to www.weightwatchers.fr ;-)
>
> Luc
>
>>
>>
>> best,
>> Esteban
>>
>> On Jul 20, 2012, at 9:48 AM, Torsten Bergmann wrote:
>>
>> >
>> >> I disagree in general with extend vm complexity to add things that can >perfectly work in smalltalk or using a FFI package...
>> >
>> > Saying you can do this using FFI/OSProcess is a weak argument.
>> > "fopen" could be in the Smalltalk image as well - but we have it
>> > in the VM.
>> >
>> > We may include both into Pharo - so nobody has to load FFI + ConfigurationOfExternalWebbrowser.
>> >
>> > But I dont think that is the route for Squeak, Cuis, ...
>> > These Smalltalks may profit from an VM implementation without
>> > making them "unsafe" or more bound to native OS with FFI and
>> > OSProcess.
>> >
>> > How can we proceed in the discussion? There are pros and cons
>> > for both sides. Should we vote?
>> >
>> > According to
>> >
>> > http://www.googlefight.com/index.php?lang=en_GB&word1=URL+with+FFI+and+OSProcess&word2=URL+within+VM
>> >
>> > "URL within VM" seems to be the winner ;)
>> >
>> > Thanks
>> > T.
>>
>
>