[Vm-dev] Request: VM support for opening browser
luc.fabresse at gmail.com
Fri Jul 20 09:33:15 UTC 2012
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,
For the subscription of the VM to www.weightwatchers.fr ;-)
> 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 +
> > 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
> > "URL within VM" seems to be the winner ;)
> > Thanks
> > T.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev