http://www.perlmonks.org?node_id=637643


in reply to Re^2: How to answer "Perl is not secure" objections?
in thread How to answer "Perl is not secure" objections?

While we are on the subject, of a "Perl browser plugin" , like the libjavaplugin_oji.so in our browser's plugin directory; what has stopped the Perl developers from doing this? From my limited understanding, the java plugin is just a java interpreter with the functions which pose a security risk removed, leaving only simple computational and display functions, and which limits display in the parent's (browser's) allocated window.

When I build Perl, I see the mini and micro Perl interpreters, which are limited versions. Would it be that hard to modify those to be a secure browser plugin? Then maybe add a chopped-down Tk or Gtk2 display engine to it? Now I wish I studied c in more depth. :-)


I'm not really a human, but I play one on earth. Cogito ergo sum a bum

Replies are listed 'Best First'.
Re^4: How to answer "Perl is not secure" objections?
by mr_mischief (Monsignor) on Sep 07, 2007 at 14:47 UTC
    Other than that very few people get paid to develop perl when compared to the JVM and Java JIT systems, I'm not sure what else would be preventing this. The P5P work very hard to improve the major targets for perl as it is, and I'm not sure that adding another target is on their radar. The Perl6 and Parrot hackers are busy doing their stuff, too. It'd likely need to be a dedicated port team tasked with building and maintaining such a beast.

    I'm not sure if Tk or Gtk2 would even be the best display technology, at least at first. That would target Flash and Silverlight pretty handily, though. What might be better at first is to interface to the JavaScript HTML and CSS DOM. Using Perl's strengths to manipulate the pages themselves could be really nice.