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?"
but IE's got COM bindings for quite some time now. (v3, and stabilized in v4).
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
No, sorry, we are just not going to do it. But thanks for asking.
Your call is very important to us, that is why we have placed your call on hold so you could here some of the best light rock favorites of the 1970s.
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.
The main reason Java Applets never became supper popular is the fact that there is a lot of overhead in them. And the fact that MS dosent want Sun to get the market share, makes sure that MS will try to hinder its performance. But Java Applets are still used a lot but now in mostly intranets or sites that expect broudband internet traffic. But for the coman user with a random selection of system the applet has not had its shine.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Applets didn't die ... they just went to a small niche, that is specific applications in an Intranet ... There you don't have to worry wether your customers want to download a 5-8MB java-plugin. The only Applets you see nowadays are cheap Flash-Replacements (most of these little Menus and Animations would be better done with Flash, and that wouldn't have given Java Applets such a bad image).
...
The biggest problem with Applets was, that the browsers just supported 1.1 (at most), and that it was faulty. Noone liked to download the big Plugins, so noone wrote Applets that used the new API, so noone downloaded the plugins,
The fact that MS provides no Java-VM in IE6 might be both good and bad for Java on the client. Bad for obvious reasons, good, because then you have to download the plugin, should you ever want to use Java. Doing this, you get a modern version of Java, and that is A Good Thing (tm).
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.
How about a browser plugin for C/C++ apps? ANybody know of one?
A Perl virtual machine IS in the works. It's called Parrot. Unlike the April Fool's "Parrot", this is an actual initiative.
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.
Theoretically, there are bindings for several languages that can be run in a JVM, using the Bean scripting framework. The list of languages that can be run in it include a subset of Perl, Rexx, Jython, Javascript...
It's just a BloJJ
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 Grail browser has python applets and has had them for many years (almost as long as Java applets have been out there). It even has a sandbox (or so the web site says, haven't looked too deeply myself). Rather than downloading a bytecode, it just downloads source code (a fairly clean approach). Now Jython or maybe even Parrot someday might be better ways of running Python applets but the Grail one is interesting at least as a historical footnote.
Last time I tried Grail it wasn't really fast or reliable enough to be my main browser, but that was many versions ago.
It doesn't look like it would be too hard to make a new version of something like grail with pygtk and gtkhtml or maybe even mozilla.
never occured to you that RAINBOW BLVD. was a reference to The Wizard of Oz (Dorothy was from Kansas, recall?)
A TCL plugin exists, but that's about everything I know of it.
Like science? Comics? Wicked...
Funny By Nature
Not sure if this really applies or not but NaN, the makers of blender use python in the game engine and plugin system. They also are developing a plugin IE/NS that allows you to play games or multimedia content in the browser. The plugin is currently in beta.
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"?
You will all die!
Glugh glaff h'laff shlrlrgh!
Iä! The hideous Tentacle Master has spoken! Obey or be destroyed!
"I would like to hear about reasons why there is no effort to expand the capabilities of websites with language-plugins"
Probably because as a concept it just plain sucks. Why the hell do we need to add even more to our web browsers when what we have at present is already hugely bloated? Even Java applets almost go too far, but I suppose they make up the functionality that is needed and would only be duplicated by implementing even more client side scripting support.
Macromedia FLASH and its non-technical ways of giving a website rich multimedia.
[alk]
The only reason the Java applets idea had a chance was that all browsers were going to support it, and even that didn't happen. Using an unusual plug-in which forces visitors to download and install a Python runtime and wrapper will quickly chase away everyone on your site. If you really need a rich GUI client-server app, there are plenty of better ways to do it than jamming it into a web browser. The browser is just excess baggage at that point.
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?
"Couldn't there be a universal CORBA-like plugin for Mozilla to be used by most languages or such?"
Right. Microsoft is so far ahead of Free Software in parasite hosting technology. Why can't Linux be a squirming mass of worms too?
BTW, Java is the standard, is it? Funny that I don't have a single byte of it on any of my computers.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
This fixes a lot of the problems that occur when you try to use applets to create real, useful programs (as opposed to little decorations, etc.) Many of these problems are caused by the conflicting requirements of trying to combine the Web world and the Java world in the same window.
Does flash/shockwave have the ability to open streams back to the server for updates (a good example is espn's gamecast - near realtime baseball game info updates)? Are the standard libraries on par with java? I am sure that Flash/Shockwave is better than java for flashing pretty pictures on the screen, but what about for real applications (not just animations)?
He hates these cans!!!
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
Two reasons java applets didn't make it:
1) Both Netscape and IE only supports an ancient version of java that nobody wants to work with. Writting an applet is a nightmare, nothing works like it is documented and you can't expect your code to work in other browsers than the one you are testing on. This would have been fixed years ago, but the first browser to use a recent JDK is Netscape 6.
2) Applets can do almost nothing with the browser compared to javascript. This reduces the potential usefullness greatly. We could have had applets that worked like client side servlets, controlling a frame with ordinary HTML etc, replacing many of the more complex usages of javascript.
If browsers used a recent JDK with usefull extensions like Java 3D available, maybe flash wouldn't have been that popular.
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
Some InfoWorld columnist found a client-server database applicaiton that was written in Flash. That's either the sign of the apocolypse or the beginning of the end for Visual Basic.
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.
Where is the link for the Java vs. C++ article you referenced?
One of Macromedia's problems is they assumed the plug-in was the way to go because Flash worked out so well. But Flash was just that, Flash. Essentially vector graphics handling in a browser. It can be used to create complex and enchanting interfaces, but it's based on a set of standards that are already being incoorporated into newer browsers.
Macromedia's product line can certainly do more than just vector graphics with paths and animations, but if you look at some of the more sophisticated tools in the product line, they required their own plug-ins and just never got good penetration because of end user hesitation to go for it.
The plugins for higher level tools like Director and more so Authorware go way beyond the capabilites of a normal browser particularly in the sense that can they read and write and delete files as they please. And much more than that, they can execute remote system functions like shutdown reboot or add registry key. So, why didn't everybody download these plug-ins? They're free just like Flash plug-ins are. I think part of the answer is that these things give a browser powers that people don't want browsers to have and so they never get downloaded. If you can make it into the HTML specs, get in a browser, if not. . .
This whole notion of letting the web turn into more than it is seems like it's the source of as many problems as it solves and it seems to be pushed by MS with this whole web sevices bullshit campaign. Fuck that, everything shouldn't happen on the web. Why does it have to be integrated into the browser instead of being its own application? All multitasking windowed computing environments allow multiple applcations to run at the same time. They can all use net bandwidth, why do they all have to be in a web browser?
It's because Perl is too ugly ;)
OK, really now:
There's not much sense in writing your own interpretor for a language with all of the modules that would have to go along with it to have any sort of functionality. And you'd have to do that because you can't trust the guy the code is coming from to not trash your box.
Peace
-Brian
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.
When you starrt the Java VM you have to compile bytecode for native operation for performance even close to fast. That's a complicated and time consuming process, and in the end you have to wait far too long on older machines before your applet is running.
If Java were just a bytecode compiled scripting language, or if it had a far less complicated VM (like, say, a 68k VM with memory management functions in the "rest" of the system, Sun could at least have native execution on some platforms, much smaller footprints for devices like Palm or Macintosh or PlayStation, and a much easier time convincing people to port pre-existing applications. Instead they made up a slow VM with a totally alien architecture, and spread some marketing around that said in this one instance a JIT was actually worth working with, in spite of all the imperical evidence in the past. This was just strange behavior.
Another option, instead of a 68k emulator, would be a tcl/tk system of some kind. There is a very large codebase for tcl/tk already, it offers decent speeds, fast download times, native widgets, and it seems to have a faster run/debug/develop cycle than Java. Unfortunately Sun couldn't take control of tcl, what with it being free software, so they made up their own crippled system as the base for a very large object tree.
"Look at me, I invented the stove!" -- Ben Franklin
i had heard that the java plug-in didnt work on ie6, that when microsoft removed the netscape plug-ins it also disabled sun's java plug-in. but looking at various pages on the plug-in, it appears that under IE, you actually load the plugin as a COM object. with the tag.
anyone try this yet? i suppose i can nuke a machine with ie6 and try it myself sometime... but i figure theres gotta be a few out there whove done this already.
this might be way off topic, but why isnt windows IE like mac IE?
on the mac, the jvm that executes is whatever jvm you have installed on the system. so if you had installed jvm1.3 you'd run that one.
I created such a system around the time Java was created (actually, it was started before Java was announced) called iHTML. It explored server-side languages that are both embedded in a document and allow DOM-like manipulation of a document (before there was a DOM, though). This isn't really interesting nowadays, though.
Yep, just write an XPCOM object to handle the scripting language of your choice. As for an equivalent to ActiveX, well it has XPInstall which allows you to install new XPCOM objects into Mozilla. These require the user to actively install them, and webpages must get the users permission to access them, but once in they're not sandboxed. Anyway, Mozilla is such a good way of writing programs that most of the time custom XPCOM objects aren't needed anyway. XML and JavaScript can do it all.
-mike
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
all thats going out the window. If you dig a little deeper your talking about IActiveScript interface.
.NET thing.
IActiveScript became the ban of my job a while back, it's buggy, barly documented overall not intended for external use. If you want to write a debugger your your neato active scripting languge you need to get into about a bizilion other interfaces called 'Smart Host'. this isn't documented beyond comments in a idl file.
anyway the whole thing is going to be abandand soon. MS is moving to a nifty
whatever.
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.
So both interpretations are appropriate.
If you are looking for python xpcom bindings, you might want to take a look at http://aspn.activestate.com/ASPN/Downloads/Komodo/ PyXPCOM/. Released under the Mozilla Public License.
I also know that activestate is working on bindings for perl which will be great for me!
on perl monks a while back.
it shouldnt be too hard esp if activestate make a plugin that comes with its windows version
more info if you search there for perl plugin
back in the day we didnt have no old school
If you like Python, you can code Java applets in Python syntax, using Java components. See Jython's SourceForge page. In particular, read Compiling Python Source to Real Java Classes
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!
http://www.rebol.com/prod-view.html
First .. lots of sites use Java applets. You can find them all over the Yahoo site, for example, and others. It's unfortunate that the browser VENDORS never updated Java past v1.1.x .. note that LOTS of work was done since then (4 years ago now) to improve the implementation, fix bugs, speed things up, and so on.
Java applet's are safer than other approaches because of the security built in. The VM, before it executes any code, runs a bunch of checks, and other checks are done at runtime. Applets in a browser has very stringent security settings and one has to jump through difficult hoops to loosen them up. Very few security bugs have been found in Java. Compare that with Microsoft's software, and the gaping security hole that is Internet Exploiter.
A new way to launch Java from a web page has been developed -- Java Web Start. It involves a small XML file (JNLP) that describes salient features and code sources for a Java app. The browser is told that for JNLP files it is to launch the Java Web Start application to run it. And, from there, all the Java code is downloaded (or may already be installed, etc) for execution. Quite easy and slick.
- David
The JVM is designed for Java and functional languages (lisp, scheme, python, Rexx). Because no pointer arithmetic is allowed, you can never have an efficient C or C++ compiler built for the JVM. Of course, anything is possible - but it would run 10X slower than compiled C code. The Java designers have seen the errors of their ways and recently added unsafe direct memory access classes in an effort to speed up graphics and IO. But they also have to create new bytecode, as Microsoft did with CLR to optionally run "unsafe" - but fast - pointer-based code if required.
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.
Try Google and search fpr Jython.
That's a Python-to-Bytecode compiler.
Yes, it's that simple
Interpreters for some scripting languages, all written in Java, already exist. (Jacl, a Java implementation of Tcl, for example.) In theory, these could run in an applet. In practice, they would probabaly have to be rewritten so the user didn't have to wait for the whole interpreter to download before a simple script would run. Or maybe the download problem could be solved by browsers' caching features. A third option would be to compile scripts to Java bytecodes and put the resulting .class files on the web server.
These options would probably be slower than a native implementation of a scripting language, but they would work on most browsers without extra plugins. If a scripting language became popluar in "applet mode", it would encourage the major browser makers to include a native engine for it.
Of course.
going to be an "ACTUAL" technical discussion here, but the moment passed
... 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.
As far as I know, Emacs/w3 has support for elisp as scripting language (instead of javascript used elsewhere).
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.
Actually there are a few things where Java is actually better. The best example I can think of is the "mirror pond" style applet which takes an image and makes a certian area of it have a water rippling/reflection look. So you take a picture of a lake and you have the water rippling. This could all be done in Flash I guess, but you're probably going to end up with a multi-frame image (a glorified animated GIF) or really crappy looking line art.
.NET follows the Java idea of using a security system - so a language implemented to compile down to the .NET framework will use it's security model, and you could therefore use those 'applets' in your web pages all you want. You'd get to use Perl or Python or whatever, you just gotta compile it down to MSIL first. :)
To make sure I stay on topic to the discussion at hand, the reason not to have a billion scripting languages available for browsers is security. Java implements a security model which gives it limited access to the user's computer. Flash essentially does the same thing (by simpling not providing any dangerous functionality).
So this means to implement languages for a browser one would need to redesign every language to have a security model, or hack out the dangerous portions of the programming languages for the web based version, or something along those lines.
In related news MS's
Yep, I wrote a chess program in Flash where the board was all done in flash and it posted back to the server to get the computer's move. The way it communicates back to the server is it sends a stream like var1=x&var2=y&var3=z... back to the server, and the server responds with a like stream back to the client (what would be really nice would be a nice SOAP interface... ahh, one can dream.)
You can program a java applet that uses CORBA to connect to a server written in a totally different language. So - your browser has done what you described for years already. Cool, huh?
Stop the brainwash
Both Perl and Python has modules that implements
Java's sandbox model (optionally), so the security issue you are talking about, are just not there.
> but I wondered why there never was a browser-
> plugin for languages like Python or Perl
I'm not a great fan of scripting languages, and when people suggest them I often scratch my head before being told that they are 'the best language for the job'. And scripting languages do have many strengths I'll admit.
However, in this case I think the language for the job must be Java since it has all the security features built in that are needed for somthing like this. It also has been around for a short time and so I guess is pretty stable/secure and well understood now.
To make scripting languages secure might mean a fundamental change to them and the way they work (Or are SecurityExceptions supported by them all as standard?).
In fact, the easiest way I could see to make a safe script interpreter would be to write it in Java! Clearly this would be slow and cumbersome, and a waste of time....
On the otherhand, if you foget security I guess that there are a lot of people out there that could quickly knockup some nifty scripts... lets just hope they aren't kiddies!
--
Mike
-- Mike
Read these articles that describe how XPCOM and XPConnect allow the mozilla framework to integrate new language bindings.
o -x pcom/
o -x pcom2/
o -x pcom3/
o -x pcom4/
o -x pcom5/
...
d o/ PyXPCOM/readme
...
http://www-106.ibm.com/developerWorks/library/c
http://www-106.ibm.com/developerWorks/library/c
http://www-106.ibm.com/developerWorks/library/c
http://www-106.ibm.com/developerWorks/library/c
http://www-106.ibm.com/developerWorks/library/c
Python bindings
http://aspn.activestate.com/ASPN/Downloads/Komo
Ruby bindings
http://rbxpcom.mozdev.org/
As mentioned earlier, Perl support is on the way.
You all tell funny true things but:
.NET or so, or not?
- I am not a windows-user and can't use ActiveScripting
- I don't wanna use java
- I don't wanna use any commercial solution
- why other languages shouldn't run in a virutal machine? (there is already Internet C, for an example)
- couldn't a CORBA-Plugin restrict usage of languages?
- Why you only talk about the impact on client-side?
If a browser could bring the server close to the client (in a sandbox), then standard desktop products could just work over internet. This means that you can use e.g. gnumeric or evolution (in a restricted way) over your browser. Think of Broadway, the concept from X Consortium, that was defined for doing that. Today it could be done with a general purpose CORBA-Interface for Internet-Browsers. It's like a free and simpe
I wrote my question about a month ago and am astonished that it actually appears, uhh..
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.
Check this out. When you install the JRE, it asks which browser you want to configure to use it. (including IE)
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.
IMHO it is a failure of OS design not to provide a sandbox into which you can safely throw *any* random *machine language* code and let it execute. The worst you should get is a sandbox violation message.
These things already exist in various forms, e.g., on a server, Apache's virtual host suexec capability teamed with careful unix permissions administration.
What's needed is a similar automatic suexec mechanism putting not just CGI code in a restricted environment, but e.g., MS Outlook when you are in windows reading your e-mail, browsers when you are browsing arbitrary places, etc.
And it has to be automatic and appropriate to the task, not just a global application of the initiating user's max privileges.
My bet is the new secure version of BSD will become a frontrunner in providing the necessary infrastructure.
Yay ruby. .NET will supply anything.
Activescript's thing of separating the functionalityh exposed by an application from the language used to script it was groundbreaking, but the interfaces aren't exactly things you can pick up and use in a day... I wonder if
Whence? Hence. Whither? Thither.
It does already exist.
Check out http://www.focusresearch.com/gregor/psh/
Unfortunately it doesn't seem to be under very active development...
BTW, there has been Tcl/Tk browser plug-in for ages. If Tcl tickles your fancy, that is.
Perl has a sandbox mode for running untrusted code. I've never used it though.
The crypto allow/deny hooks in Java always seemed a bit over-rated to me. Although they certainly have their advantages, they are incredibly difficult to set up! (Especially since the user has to muck around with the security manager--Unless they've fixed that somehow.)
I'd say perl's primary advantage over java is performance, at least in certain circumstances.
Load time is better, and text parsing speed is better. I haven't used many GUI perl programs, and have never written one, but experience shows that perl's faster at interfaces also.
Of course, if you're writing a large, complex, program, you're better off with Java....
I just read some other stuff by "Zero__Dumbass". my opinion? .
Raging ego maniac asshole whose bitterness causes him too provokes the world.
Agreed! That Zero_Credibility boy is working for Microsoft, trying to discredit our community. Beat it, kid.
-Zero_Kelvin, AKA Zero_Credibility: Snot Nosed Karma Whore Poster Child
It is amazing that MS has not yet bought Macromedia and grab instantly this market and also the market of webpage editors... Flash/Shockwave Player is bundled with XP, a rarity nowadays, given that MS tends to bundle its own stuff.
¦ ©® ±
I've tried it, and it worked quite well for my purposes. It's good for implementing plug-in reusable easily configured components, that are much simpler to plug in, more reusable and easier to configure than anything you can do in straight-up JavaScript.
There's a technology called "Dynamic HTML Behavior Components", that let you package up a bunch of JavaScript code in an XML file, describing its interface: properties, methods and events. And attach that object to any DHTML element, as a behavior that can respond to events, access dhtml tag attributes, web page content, expose methods and events, etc.
That DHTML Behavior interface can be implemented in any scripting language like JavaScript, VBScript, Python, Ruby, whatever, through ActiveScripting.
That's why ActiveScripting is so important and useful. It lets any language call and use components written in any other language, so you can both implement and utilise components from any language that plugs into ActiveScripting.
Plug-in behaviors are easy to attach to any dhtml element, like so:
<div style="behavior:url(piemenu.htc)"/>
You can easily pass arguments to configure the behavior through dhtml attributes, like so:
<div id="Pie" style="behavior:url(piemenu.htc)" piemenu="MyMenu" fixedradius="40" onselect="MyHandler()"/>
The component exposes properties and methods you can access from scripts on the web page, that cna be written in JavaScript, VBScript, Python or whatever. Like so:
Pie.fixedRadius = 40
Pie.DoPie(Pie.GetRootPieMenu())
And the component can access embeded "XML Data Islands" on the web page, or dynamically created by JavaScript code, or downloaded from a server, or dynamically generated from a database, or the results of evaluating and XSLT style sheet, etc. XML data islands are a great way to embed XML data on a web page, that the scripts as well as the components can access. XML is a perfect way to represent the tree structure of pie menus, as well as embedded XHTML that specifies the presentation of the pie menu items and middle. So you can configure the pie menu component on the web page by embeding an XML data island inside the element to which you attach the pie menu behavior. Like so:
<div style="behavior:url(piemenu.htc)"
id="Pie"
fixedradius="40"
onselect="HandleSelect(event)">
Click here to pop up a pie menu.
<xml>
<piemenu name="Hello World">
<html>
<B>Hello</B>, <EM>World</EM>!
</html>
<item name="Hello"/>
<item name="World"/>
</piemenu>
</xml>
</div>
My point is, that this technology saves a lot of time and effort, and makes it quite easy to implement powerful reusable modular components, that are in turn extremely easy for other people to use.
If anything in Internet Explorer is worth for Mozilla to emulate, it's the ActiveScripting and plug-in DHTML Behavior Component technology.
Stop bashing it out of ignorance, and learn about it. Then figure out how to support it in Mozilla.
Don't try to come up with something better, when you're already so far behind, and 95% of the world is already using Internet Explorer. That's why Mozilla is so far behind. They've been pissing away time trying to implement all these untested half baked ideas, instead of putting time into supporting the standards that already exists, like Microsoft has already done.
Don't believe me? Let me recap some of the promises Netscape made, but never kept, when they should have been working on standard support for DHTML, XML, XSLT, and ActiveX.
The Netscape plug-in API is trivial and useless compared to ActiveX or even the older OLE stuff. It didn't need to be as complicated as OLE, but it sure needed to be a whole lot more powerful and not as half-baked as it was.
Rewriting the browser in Java. They put a whole lot of time and effort of good people into that project, and it finally went nowhere. Netscape exployees couldn't stand working with Sun employees because they were arrogant and bickered all the time, so they couldn't get along well enough to produce anything. The project got canned.
Supporting OpenDoc. Netscape was OpenDoc's last hope. It held the promise of a real component system. More than that, OpenDoc's "killer app" was CyberDog, which was a totally beautiful component oriented web browser. (Well, a lot more than that, because of OpenDoc, but that's how they were selling it.) Of course the implications of integrating OpenDoc and Netscape were that they had to flush everything they'd done so far down the toilet and start over, possibly with CyberDog, or else from scratch. But Netscape was too arrogant to throw out what the'd done so far and take any advice from Apple. Mozilla was a huge monolithic monster that couldn't be simply broken down into a bunch of independent components. No fucking way. One or the other had to go. So after publically promising to support OpenDoc with great fanfare, and hiring the CyberDog team away from the already poor shrivled Apple, Netscape resolutely shot Old Yeller: they killed CyberDog, thus driving the last nail in the coffin of OpenDoc, and summarily fucking both Apple and IBM.
Sun observed OpenDoc's demise and the resulting fallout with the bearded delight of Osoma bin Laden watching CNN, because they wanted to promote their "100% pure" fundamentalist religion of JavaBeans (which at the time only existed as a widely announced name, and wasn't event designed yet) as the one alternative component framework to go up against ActiveX. But OpenDoc was in the way, so they danced on its grave when it died.
Then there was the time that Netscape hired a bunch of former NeXT guys, who had learned Java and decided to implement a NeXTStep-like toolkit in it. It worked really well, and looked really good, so Netscape hired those guys right up, named it "IFC" for "Internet Foundation Classes" so as to position it against MFC "Microsoft Foundation Classes", and announced that IFC was going to be the official "100% Pure Java" cross platform write once debug everywhere bla bla bla widget component toolkit for Netscape.
But the idea of another Java toolkit that wasn't vapourware spooked Sun, who was still vaporising their plans for JavaBeans and didn't want IFC taking away any of their media attention and mind share.
Sun was afraid of IFC because it had such a great name (nothing about the architecture mattered, except that it was not JavaBeans). IFC was what you got when you took the widely successful Microsoft Foundation Classes, removed the Microsoft, and replaced it with Internet instead. Yes, that kind of thinking really floats the boats of marketing people.
Sun saw IFC as a threat, as long as it was not under their control, so they called in an old favor they did Netscape, when they let them use the holy name "Java" to brand their scripting language that really didn't have anything to do with Java.
So Sun called in the "JavaScript" name favor, and Netscape turned IFC over to Sun in order to be "migrated" and "readjusted" to JavaBeans. Which really means they just disposed of the body, but stored the name away safely for later use.
Anyway, after all that, you can see why I have absolutely no faith in what the religiously anti-Microsoft zealouts come up with. Because their thinking is so clouded by their warped little models of the world, that no matter how good their technology is, they will destroy it for petty, stupid reasons.
Disclaimer: This is all my own warped and interpreted view of the world from my own perspective, as an ex-Sun-employee with an axe to grind, and other undocumented perspectives that I won't go into now, to protect my informers. Take it as fiction if you like.
The part about pie menus isn't fiction, though. You can download the free open source, documentation and demos at:
http://www.piemenu.com
The JavaScript pie menus for Internet Explorer 5.5 on Windows are at:
http://www.piemenu.com/JavaScriptPieMenus.html
And if you don't believe that pie menus are faster and more reliable than linear menus, you can prove it to yourself by playing the game "Fasteroids", and read all the source code if you don't trust me.
http://www.piemenu.com/fasteroids.html
As I said, it requires Internet Explorer 5.5 on Windows. But that was the whole point of this discussion.
-Don
Take a look and feel free: http://www.PieMenu.com
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.
JPython is a pretty complete version of Python in Java. So you don't even need a plugin to use Python on a Web page. But, you do have to wait foor the jpython jar file to download.
After Netscape 2 came out, EVERYONE had a java applet on their page. Being it was a 'new feature' in the eye's of many, it must be abused. There was a period of about 6 months where there were more lame scrollers on pages they anyone with taste could take.
Eventually it died down as people got over the 'new feature' buzz and remembered they had taste..
- My Blog - http://www.memestreams.net/users/rattle/
This might not be exactly what is meant by 'browser bindings' , but something that has always seemed to me to be missing from Netscape/Mozilla is the ability to define key bindings to do different things, i.e. open a particular boomark or run some javascipt function. As someone who prefers to keep their hands on the keyboard, I would find this very useful. Also, it would make the web browser more like.....EMACS. M-x praise-emacs!
Actually, why not make the entire browser LISP-extensible?
etc etc..