Slashdot Mirror
Browser Bindings for Python, Perl, and other Languages?
Garfycx asks: "Hi everybody! This week Slashdot linked to a story about Java and its roll over C/C++. While reading it I remembered one of the first strategies to make Java a de-facto standard - the browser-applet. as far as I know it did not make it, and I don't see many of them in cyberspace. But in combination with servlets they may come up again. I am not quite sure who is in need of applets but I wondered why there never was a browser-plugin for languages like Python or Perl. I would like to hear about reasons why there is no effort to expand the capabilities of websites with language-plugins. Couldn't there be a universal CORBA-like plugin for Mozilla to be used by most languages or such?"
Of course, the problem is that a web site owner can't assume that an end user has a given language runtime installed. So that limits how you can use it. But it could have great applications on intranets where you have more control over the client situation.
ActiveState has versions of Perl, Python and TCL that follow these API's on Windows. Here is a session they were going to do at the cancelled O'Reilly P2P conference on using this stuff
Java was (and still is, to an extant) popular as web applets because it allowed developers to put multimedia content (animations, sounds, games) on their pages very easily. Perl and python, while great languages, really don't have that sort of multimedia ability (or bloat). For this reason, they're less desireable for client-side applets.
I'm the stranger...posting to
how do you sandbox the implementation ?
java has lots of features to run in a sandbox and verifying the bytecodes + grant access if you ask for it
this would have to be added to any other implemtation
fankly I dont need another way of downloading rubish
text is enough to conveiw most information well why do you need anything else?
(pictures are handled by jpeg and PNG )
so WHY ?
games I think are the most use I have played lots of flash and applet golf games on the net but appart from that I have never used applets
oh and I think that phones running a java VM(so you can play games appart from snake) will be more prolific over the next 2 years so that battle is over
regards
john jones
flexible security model
Permissions are split into several categories, and a user can grant or deny permissions for each category instead of a blanket grant-permission for everything an applet might want to do to your machine.
platform independence
the Java standard library's API is written to abstract away a lot of platform-specific foo that you find in the standard library of other languages.
performance
yeah, Java takes a lot of crap for its performance problems. But Sun has spent almost a decade optimizing their VM to make it as fast as possible. An applet language MUST run inside VM or interpreter (for security and platform independence reasons) and writing one that provides even marginal performance for computationally intensive stuff is no easy task.
Erm, isn't this simply because Java runs in a virtual machine. The point is that Java runs in a sandbox, which is supposedly separate from the rest of the processes running on your machine, so that it should be more secure, and can't run arbitrary code on your machine.
If you're talking about simply letting a browser run any code on a computer simply by going to a page, then it's fairly obvious why this is a terrible idea - it lets a web page author run any code they like on the computers of anyone that goes to their page.
Perhaps I'm being dim, and missing something, but if I'm not, that seems blindingly obvious to me.
Hmnn.. not sure about CORBA, but perl applets? Doesn't make much sense to me. That's not what perl is good for, and it's certainly not what it was designed for. Anyway, Perl is already at large, on the internet, doing (arguably) what it does best - CGI.
<offtopic> What I would really like to know is, when the hell is someone going to come out with a "psh"? Imagine it.... a Perl Shell. mmmmmmmmn
Internet Explorer can use any language supported by Windows ActiveScripting, which include VBScript, JScript, and even Perl and Python (with ActivePerl/ActivePython from ActiveState).
But the client needs to have these installed, and they are not as secure as JavaScript because they give access to the whole set of Perl's and Python's functions, allowing things like file i/o on the client's disk (which VBScript also allows if i remember correcly).
So they should never be enabled in a web browser, because of the security holes it opens.
IE ships with ActiveX/COM support, which provides a language-independent mechanism to plug anything you want into your browser. The user gets code-signing and some level of download control, but ultimately there's no 'sandbox' to prevent that code from doing what it wants (deleting your home directory, e-mail bomb, etc). They've been ripped for the security implications, as anyone who reads Slashdot knows.
.NET approach will be the hybrid. While you still have a Java-like runtime that has a security model, at least you won't be locked into a particular language.
Netscape chose the safe route and only provided Java applet support. This relies on the Java security model to protect the user through sandboxing from anything that they might automatically download, but locks you into Java. Mozilla/NS6 may allow some sort of XPCOM application to be downloaded and installed, but it's not as seamless as ActiveX.
The important point is that you don't get 'unsafe' languages like C++ and Perl in your browser without the security implications that everyone's roasted Microsoft's ass over.
The MS
Whenever I hear the word 'Innovation', I reach for my pistol.
Back in the early days, everyone lauded Java as a means to add multimedia content to the web. However, specialized system (flash/shockwave) for this have proved so much better at this than Java that Java is essentially dead in this area. If someone is using Java for multimedia on a webpage nowadays it simply means they haven't learned how to use flash yet.
Jython is one solution for Python applets. Jython is basically Python compiled into Java. It works well enough to be used for applets.
:-)
http://www.jython.org/applets/index.html
There are a couple of downsides:
- The Jython library has to be downloaded with the applet. It's about 200K. Over a cable modem it takes 0.7 seconds, though.
- Can't use Python extensions.
But there are also a few really good things:
- Jython lets you use the mature AWT/Swing libraries, which are better than Tk. They aren't as good as wxPython, though, IMHO.
- It's a stable platform that works with all Java-enabled browsers already. And Jython continues to receive improvements.
- The *HARD* part about applet-enabling a language is figuring out how to restrict applets without curtailing the language. Sun has achieved that to a reasonable degree and Jython takes advantage of their work.
What I'd like to see is the Java plug-in simply including the Jython library as a standard class library. That would eliminate the download time.
Use Zope!
There is a plug-in for TCL/TK. I don't know about Python and other languages (e.g., Scheme and other LISPs). But perheaps, no one else cares about stupid web-crap :]
--The knowledge that you are an idiot, is what distinguishes you from one.
As this same functionality is in MacOS X (and I believe in it's peer Open Source " Darwin ") the technology is availiable for others to review, compare/contrast, even appropriate. Whatever you think of Apple it's an interesting technology and has already proven it's worth with almost all MacOS applications being made AppleScriptable (and hence everything-else scriptable) for years.
I don't read ACs: If a post isn't worth so much as a nom de plume to its author then I wont bother either.
I think the major technical stumbling block to allowing applets or scripting in any language is finding a language-neutral way of restricting execution along the lines of Java's security model.
That's a really hard thing to achieve correctly - and if you don't get it right then your browser is swiss-cheese. Even harder is to get it right, cross-platform. Under a *NIX you could run whatever external code in a chroot environment to stop it from messing with any of your files... but what's to stop the code DoS'ing you by opening thousands of windows?
Individual languages have their own security models and restricted execution environments (Python has the Bastion module for instance) but it would be a veritable Tower of Babel trying to support every security model that every language implements (and of course, many languages don't even have the concept).
You could create a standard security model that is implemented through a very restricted set of APIs that are all that's exposed to foreign code, and attempt to disallow any other access (a la COM) but experience with COM tells us that this is not really tremendously secure at all without a generally more robust security model in the OS. You could achieve it using the Linux capabilities model and it would be secure, but then it would be impossible to implement cross-platform, and you'd probably still have to extend capabilities further in order to prevent external code from DoS'ing you with new windows.
All in all, it's just too fraught with difficulties to really make it worthwhile.
Then there's the question of support - implement a fantastic new security model that allows you to run any language within a completely foolproof sandbox, great. Now, how many IE/Windows users will download your plugin? How many of them have Perl or Python installed? I'd put the number at something approaching zero, and with 80%+ or whatever of the browser market being IE these days, I can't see this ever taking off, even if it became a standard feature in every other browser on the planet.
Maybe it could work on an intranet, where everything is secure and controlled. But in an environment like that, you're probably better off writing a simple browser plugin that's installed on every machine anyway rather than having the machine download and then execute the code.
On the open internet, I think it would probably be either a complete non-event or a security disaster.
Or maybe they just don't want to shell out for flash.
I'm the stranger...posting to
the browser-applet. as far as I know it did not make it, and I don't see many of them in cyberspace.
followed by...
I wondered why there never was a browser-plugin for languages like Python or Perl.
Well, if applets aren't that useful in Java, it should be obvious that they aren't that useful in Python or Perl either. Try to imagine somebody at some company going to a VC with a business plan of "we're going to do something that will require the user to download a plugin and it will do the same thing Java does."
I would like to hear about reasons why there is no effort to expand the capabilities of websites with language-plugins.
There are now many languages for the JVM. There is a good chance that you can finagle your favorite language onto a JVM somehow. This is more work for the individual programmer, but it requires no effort on the part of users. Remember, when you put something on the web it has to be viewable by most users, otherwise it will just alientate them. When you get one of those boxes that asks you to download something just so you can view a website, how often do you click Yes?
So, if [other language] had trumpted a platform neutral VM first we would probably be asking the same questions about [other language]. Java got there first and has established a huge installed base and name recognition, so until something comes along that just blows it away in terms of capability, programmer-friendliness, or installed base we are stuck with it. So far, MS CLR looks like the only thing that has a chance at doing that, and it is more friendly towards implementing a wide variety of languages than the JVM.
The CLR/C# developers seem to have a thing for functional programming languages, so stuff like OCaml and Haskel (sp.?) could get a shot in the arm from C#.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
The real trouble is that very few widely used operating systems can properly jail an executable. FreeBSD tries, but the jail facility in FreeBSD doesn't get used enough to establish that it's safe.
NSA Linux, which has mandatory security, is a big step in the right direction. A good exercise would be to make Mozilla run uner NSA Linux but insist that downloaded code run in an untrusted compartment, so it couldn't do much.
that is well, offtopic, but here goes.
Smart bookmarks in Galeon allow you to search websites by inputting the search text in a text field from within a Galeon toolbar. This is quite cool for sites like Yahoo, but Amazon cannot be searched in this manner because it requires a FORM/POST method to search the Amazon site. Same for my fav website of all time, Digikey.
Anyone know of a way around this?
Umm..actually, yes it does. The scripting allowed in Flash, especially Flash 5.0, is amazing. We have built chat clients, news tickers, etc. The other great thing about it is that it can interact with whatever Server-side scripting language you are using, be it ASP, Cold Fusion, Perl, etc.
I think the challenge is that because Flash is still new, lots of people are just using it to use it. But just like with any other system, you will start to see more and more applications built out of it that utilize its true power.
Random Musings
That may have been its most obvious selling point, but that was far from it's only use. It was a cross-platform method of client/server programming. You could develop sophisticated applications with incredible performance characteristics (compared to simple DHTML) that you could distribute to a heterogenious intranet (Solaris/Linux/win32).
Eventually DHTML got more sophisticated, and generating graphics for HTML was an order of magnitude simpler than for Java. Thanks to more reliable javascript, you can also produce many of the dynamic operations that previously required Java. (procedural drop-downs, tabbed pages, refreshing, etc).
-Michael
-Michael
I would like to hear about reasons why there is no effort to expand the capabilities of websites with language-plugins.
Because the idea sucks. The place for code is on the server, not the client, for the following reasons:
1. Security
2. Compatability.
3. Portability.
4. Separation of presentation and logic.
The only time where it is possible to put logic on a client and get reliable performance is where you have complete control of the client's software and hardware - i.e. a closed computing environment.
That is NOT the web.
How about a browser plugin for C/C++ apps?
In this case, the applet *is* the plugin. Simply write your "applet" using the plugin API of the given browser, compile for whichever platform you want, and there ya go!
Of course, a much more "interesting" solution to this would be to write a browser plugin that contains gcc/g++ and all appropriate libraries. Your applet would then just be C or C++ source code, and when downloaded, the plugin would compile and run it for you! In addition, you'd be able to run your applets on any platform that you ported your plugin to. Aside from the obvious security issues with untrusted C/C++ code, and the *size* that this plugin would be, you have to admit, it'd be a very hack-worthy thing to do!
It's only software!
Java presented itself as a rich medium in which to be able to effect much more complex interfaces. Sure, there were much more grandiose plans, but this is what most people wrote applets for. Ultimately, this proved to be a problematic architecture for a number of reasons (not limited to flaky OSes, lousy java implementations, limited sandbox behavior, and the problems of native UI elements across platforms). I spent many long nights frustrated while trying to develop mission critical communications applications in an applet environment.
A combination of more advanced HTML behaviors (including DHTML, XHTML, etc.), better client side scripting, and robust server side environments has emerged as the dominant model and has a lot of strengths to speak for it. Compared to applets, we get more flexible, supportable, and scalable environments and can much more easily reuse behavior across into other areas.
With some apologies to Perl/Tk, wxPerl, and other projects, building a nice user interface has never been a strength of Perl. I love perl and think its a great tool, but its not what I reach for out of my toolbox when user interface problems present themselves. Python is arguably a little more relevant here, but I still don't see a compelling extension of behavior worth the costs of runtime footprint, learning new code, and inevitable incompatibilities. mod_perl is clearly a compelling use to me as I can do innumerable little tasks quickly and easily on my webservers, do I really need super nifty regexps and unix tool linking in my browser's client runtime?
Where you really do need more advanced behavior (which is far less often than people think), Flash and Shockwave are probably better solutions, particularly from the perspective of designers and content people. And beyond that, an ActiveX control (face it, windows is the dominant user platform, like it or not) lets you accomplish whatever you need more flexibly.
Lanugages can be a lot of fun to play around with (Ruby and Haskell come to mind right now), but generally speaking its better to minimize the number of tools used and requirements imposed (particularly as we start focusing more on embedded browsers).
... rjs
Grail was a browser written years ago in python + tk. Its features included python applets, that would be downloaded and run in a restricted execution mode in the browser. Not often mentioned, but python may have been the first 'applet'-capable language.
Not exactly. The two major speed issues with running Java applications are:
- the startup time of the JVM before the bytecode starts running (or is even loaded)
- the speed of the GUI libraries (AWT & Swing)
The first one is a pain-in-the-ass, especially for small applets or applications that don't do much themselves; why should a seemingly insignificant applet take a long time to start? The second one is the main reason why people consider Java to be "slow". It is (hopefully) being addressed in the next version of Java, although this won't help most browsers that use a version of Java that's several years old.Those issues aside, Java is actually a relatively quick language. Using such tricks as just-in-time compilation to native code (this is done as the bytecode is running, and uses various code profiling techniques), the speed of a java program can approach that of a natively compiled one.
It's only software!
What MS did is remove the ms vm and disable netscape style plugins. The old sun plugin was a netscape style pplugin.
Sun now has a beta version of jdk1.3.1 (in their early access program) that replaces the MS vm entirely. It is an activex plugin and it will even run applets defined in applet tags.
If you go to www.javasoft.com/jdc and sign in (for free) you can download it. You'll notice that sun has put up a call to testers to test it with existing applets in order to find compatibility problems.
It works great with IE 6 and I haven't found any applets yet that I can't run. It's stable too, no crashes so far.
Jilles
Dolphin Smalltalk has a plugin as well. However, like Dolphin Smalltalk itself, it is Win32 only.
One of the bigger, more business oriented Smalltalks, VisualWorks, also has a plugin. It looks like it too is Win32 only, but VisualWorks itself is cross-platform, and runs on Windows, Mac OS, and a big number of Unices.
The coolest plug-in for a language I've ever seen has got to be Oberon's Juice, by far. Unlike the Java and Squeak VM plug-ins, which take bytecode for their respective VMs, the Juice plugin takes pre-parsed Oberon code and compiles and executes it on the fly. This makes for really fast applets. I tried it a while back and it took a heckuva lot less time for Juice to download, compile, and execute the applet than it took for a comparitive Java applet to start up. Really cool stuff. However, it seems it's not been maintained in a while, and is Windows and Mac only. Seeing how Oberon itself has source available (IIRC), I'm sure that some Oberon enthusiast who wanted to get a generized Unix version going of Juice could do so.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
Well, since the Java Virtual Machine runs bytecode, not source code, you should be able to compile any language into Java bytecode.
g++ can compile C/C++ into Java bytecode, can't it?; I'm sure it or other compilers can do the same for other languages.
Then, assuming everyone has a Java virtual machine, you're all set; except for languages like Perl which aren't compiled -- that sucks, but hey you can't blame the virtual machine for the limitations of the language.
I don't want to argue about whether the user sees the "do you trust this" message every time or whether it can be hidden using BudAPI or something you cook up on your own, but basically Authorware is worthless unless you can make local system calls. If you just want to display text and some pics and play some sounds, why not just put up a web page? This explains why Macromedia started pushing Dreamweaver so hard even when they already had superior products from a development point of view. Nobody was downloading the plug-ins.
It still stands that people don't want to download the plug-ins even though they're only a meg or so. That was my point. I'm not acusing these tools of being a security concern or saying security concerns are why they aren't downloaded, the fact is these plug-ins aren't downloaded by most users for whatever reason. The Flash plug-in was an anomaly because people are like fish and other creatures possessed of eyes and they like to see flashes of light. It was stupid human trick. Plug-ins as a solution suck. Browsers are already way overloaded and it's all MS's attempt to focus everything on the web because it's the one part of the net where buzinezz ownz ur azz.
Well that is hot the only reason. Java applets do not perform the same way in all browsers. Each version of Netscape supports a different JVM. Even on different platforms, the same version of NEtscape did not support the same JVM. I tried this once and found my applet was different in IE on windows 95/98 and differnt on NT and different on LInux. Then mozilla is a different JVM, which crashes my browser, so I don't use it.
There is also little reason to use applets. The only effective place I have seen a java applet was a chat application that was a trusted applet. Outside of trusted applets, you really cannot do a whole lot.
I think the other reason is that they take to long to load on a page. I have only seen a few good applets.
May your ass bleed profusely for every negitive moderation point this post gets!
Only 'flamers' flame!
Once in a while you actually want to run client-side software via the Web, and then you want an applet. For most people, however, this is very rare. I'm not against applets (I wrote an open-source planetarium applet, and it's moderately popular). I'm just against using them in stupid ways. And, as people have already said in other comments on this story, it's nightmarish to consider the security problems that would come up if you allowed applets in languages that weren't specifically designed with Java's security and no-crash features. The same things that make me enjoy programming in Perl more than in Java are also the things that make Java applets safe for users.
Find free books.
... you may as well use one of the most commonly installed one. Using Ming you can generate Flash on the fly using PHP. Most popular plug-in + most popular scripting language = common sense to me!
Phillip.
Property for sale in Nice, France
Standard Python could also be used in Mozilla through XPCOM but you would have to be careful from a security point of view. You could only really run trusted code.
The reason that other languages do not work as well as java in the applet context, is that in order for an applet to be able to be used freely on the web, it must provide cross platform support. Also, it must have some type of security sandbox or no intelligent user is ever going to let it execute. Java provides both of these without any extra complicated programming hacks. As well as having already established itself as a comptent de facto standard.
The reason that applets have never really made it big is essentially two fold. The first is the shitty virtual machine that most browsers have. IE runs a semi 1.0--1.1 compliant browser and there have been significant changes since then (Swing anybody?). The other reason, and perhaps more important is that there are only a few instances where applets are really needed. If all you are doing is displaying semi-dynamic (aka database driven) content, which is all the pretty much every page on the web does, just use some sort of php/jsp/cgi type solution and your fine, it's faster, and easier in general. If you need a little bit of client side dynamics, you can throw in a little dhtml/javascript and have your form validation and pretty scrolling text or whatever. The real use for applets come when you need a much more interactive sort of web application, where the display needs to be updated constantly, or you need to do a lot of dynamically generated graphics or very complex data processing. These types of apps appear much more frequently on intranets than they do on the web in general, and provide a much richer interactive experience.
One aspect to the slow GUI is alot of people seem to skip the chapter of their textbooks practically begging them to thread their programs properly. You can make your GUI very responsive if you lock it down inside a higher priority thread or thread each section of the GUI depending on the frequency it needs to be updated. I've seen far too many applets with everything from the AWT objects to all the functional methods confined to a single thread. AWT is slow enough but managing it poorly just gives your apps a bad reputation. If you thread it, they will come.
I'm a loner Dottie, a Rebel.
As for security implications, a script context is only as dangerous as the power you expose into it. Javascript is only considered a "safe" language because it typically doesn't have access to any objects that can do damage.
The fundamental difference between IE and Mozilla is that IE automates this process of downloading and installing COM components, whereas Mozilla makes it quite cumbersome. It does have an automatic installation facility in the form of XPInstall but it hasn't been picked up by plugin developers.
The principle problem of automating everything is that the user in general hasn't a clue whether a control is trustworthy or not. Yet a control can be downloaded, installed and run on their machine to do anything it pleases with a few mouse clicks. Manual installation may be more irksome but it gives a novice pause for thought and discourages web sites from using controls in the first place.
There used to be a web-browser that did this with Python called Grail. It is now defunct, but you can see what's left of it at http://grail.sourceforge.net/.
-- Slashdot sucks.
I'm sure that once .net comes along IE will support running programs on the CLR, which has sandbox capabilities, much like the JVM. I know that Activestate has .net versions of perl and python, which should be able to run on a CLR-capable browser. With any luck the mono project can get incorporated into browsers such as Konqueror and Mozilla, so that we can have CLR-enabled browsing for everyone. I also hope that some platform-independant standard is developed for doing browser-based multimedia on CLR, but I'm less optimistic that that will happen.
How many plugins can you name that don't suck? All plugins manage to do is make websites a pain to program and a pain to use as you have to make sure the user has the right plugins which of course means you have to figure out if the plugin is installed, is it the right version, does the plugin exist for XYZ OS/platform, what do you do if it doesn't, etc.
:)
:)
Not really a very good system. Java or one of the languages it copied was supposed to fix all that but it obviously never made much impact in real life (most good Java I've seen was server-side). Embedded scripting languages such as Javascript help and having a few more choices such as Python and client-side PHP/SQL would be nifty but it still doesn't really address all the issues.
A client-side multimedia-oriented scripting language would be really cool and would handle what most plugins do. Maybe one of these XML'ized mutlimedia standards or Shockwave or something could fit this bill if used right. Anyone know?
Semi-related question.. why don't DVD's use XHTML plus some built-in scripting languages rather than using Windows-only extented shit and butt ugly menus? A good multimedia scripting language would kickass on such a platform.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.