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?"
bitches
but IE's got COM bindings for quite some time now. (v3, and stabilized in v4).
This story's date wouldn't be wrong if slashcode and everything else was written in FORTRAN, like it should. Damn kids.
Holy shit! I couldn't wait to get into work today so I could share my latest breakthrough in busting the Kansas City Gay Faggot Sex Empire!!!
As I was driving to work, I passed a road right inside of Kansas City limits! The road had a name: RAINBOW BOULEVARD!!! I consider this incontrovertible proof that Kansas City was not founded on American principles of freedom and liberty but on the turgid platform of depraved homosexual lust and faggotry.
Let's linguistically examine what the cockfiends and perverts had in mind when they engineered this city.
As if Rainbow Boulevard isn't obvious enough already, a deeper look reveals to us a message concerning homosexual recruitment: rave! i do urban blow! entices young hairless boys to come to raves, roll on xtc, and administer blowjobs to the urban dance folk while WHAM! and Culture Club dance remixes pump at a frantic beat.
Another oft-used street in downtown Kansas City is Broadway. The street takes its name from the singing and dancing circuit that is commonly associated with fags who aspire to "make it big" (a reference to hardened penises) performing the arts and letting their souls dance free on stage in front of millions. Quite simply, Broadway is a thinly veiled anagram for Boy Reward: this street attracts members of the boy-slave trade, who kidnap and sell young men into the Gay Faggot Sex Trade on Butt Hill.
The War Memorial, as in Kansas City's giant phallic symbol and the watchtower of the faggot prostitutes of Butt Hill, unveils even more sinister plans crafted by the city's civil engineers: aim lower, ram! is a subliminal message which promotes the correct placement of the penis in the anus, or "ass-cunt," of another male! Likewise, it doesn't take a genius to see the phrase amoral, we rim!, which seems to express the fact that those who give rimjobs in Kansas City (i.e., most everyone) are proud of their existence without morals. And we can't forget rim alarm woe, which is what happens when a lusty boy-twink licks clean an HIV-positive man-bear's asshole. This has to be some kind of sick public service announcement emanating from the War Memorial!
Moving on, we come to Kansas City itself. I almost wanted to cry after unearthing the hidden meanings of this seemingly innocuous city name. The first reveals what is surely the root of Kansas City's homosexuality: Satanic sky. Only the Dark Father, casting his cloud of disease and Hellfire, could cause a city to be as morally repugnant and cock-lusting as Kansas City. Sodom, watch out! The cum flows like water here, and makes even San Francisco look like a good, Christian vacation spot
Kansas City also translates into a pair of filthy sexual phrases: a stinky sac describes what most men in Kansas City think about all day and would like to have tickling their chins at any given moment, while tick any ass is so obvious it hurts to think no one's spotted this anal anagram for the city's name before now. Thank god I am on the case.
Well, I'd better get going. I don't want detected by the KC Faggots while I'm trying to bust their Cum Ring. I plan on camping out on Butt Hill to infiltrate their depraved, underground male-sex trade. Hopefully I'll make it out and write of my findings.
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
Cliff has ended the Michael story marathon.
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.
Young Zaphod Plays It Safe
by
Douglas Adams
A Short Story By Douglas Adams
A large flying craft moved swiftly across the surface of an
astoundingly beautiful sea. From mid-morning onwards it plied back and
forth in great widening arcs, and at last attracted the attention of the
local islanders, a peaceful, sea-food loving people who gathered on the
beach and squinted up into the blinding sun, trying to see what was
there.
Any sophisticated knowledgeable person, who had knocked about, seen a
few things, would probably have remarked on how much the craft looked
like a filing cabinet - a large and recently burgled filing cabinet
lying on its back with its drawers in the air and flying.
The islanders, whose experience was of a different kind, were instead
struck by how little it looked like a lobster.
They chattered excitedly about its total lack of claws, its stiff
unbendy back, and the fact that it seemed to experience the greatest
difficulty staying on the ground. This last feature seemed particularly
funny to them. They jumped up and down on the spot a lot to demonstrate
to the stupid thing that they themselves found staying on the ground the
easiest thing in the world.
But soon this entertainment began to pall for them. After all, since
it was perfectly clear to them that the thing was not a lobster, and
since their world was blessed with an abundance of things that were
lobsters (a good half a dozen of which were now marching succulently up
the beach towards them) they saw no reason to waste any more time on the
thing but decided instead to adjourn immediately for a late lobster
lunch.
At that exact moment the craft stopped suddenly in mid-air then
upended itself and plunged headlong into the ocean with a great crash of
spray which sent them shouting into the trees.
When they re-emerged, nervously, a few minutes later, all they were
able to see was a smoothly scarred circle of water and a few gulping
bubbles.
That's odd, they said to each other between mouthfuls of the best
lobster to be had anywhere in the Western Galaxy, that's the second time
that's happened in a year.
The craft which wasn't a lobster dived direct to a depth of two
hundred feet, and hung there in the heavy blueness, while vast masses of
water swayed about it. High above, where the water was magically clear,
a brilliant formation of fish flashed away. Below, where the light had
difficulty reaching the colour of the water sank to a dark and savage
blue.
Here, at two hundred feet, the sun streamed feebly. A large, silk
skinned sea-mammal rolled idly by, inspecting the craft with a kind of
half-interest, as if it had half expected to find something of this kind
round about here, and then it slid on up and away towards the rippling
light.
The craft waited here for a minute or two, taking readings, and then
descended another hundred feet. At this depth it was becoming seriously
dark. After a moment or two the internal lights of the craft shut down,
and in the second or so that passed before the main external beams
suddenly stabbed out, the only visible light came from a small hazily
illuminated pink sign which read The Beeblebrox Salvage and Really Wild
Stuff Corporation.
The huge beams switched downwards, catching a vast shoal of silver
fish, which swiveled away in silent panic.
In the dim control room which extended in a broad bow from the
craft's blunt prow, four heads were gathered round a computer display
that was analysing the very, very faint and intermittent signals that
emanating from deep on the sea bed.
"That's it," said the owner of one of the heads finally.
"Can we be quite sure?" said the owner of another of the heads.
"One hundred per cent positive," replied the owner of the first head.
"You're one hundred per cent positive that the ship which is crashed
on the bottom of this ocean is the ship which you said you were one
hundred per cent positive could one hundred per cent positively never
crash?" said the owner of the two remaining heads. "Hey," he put up two
of his hands, "I'm only asking."
The two officials from the Safety and Civil Reassurance
Administration responded to this with a very cold stare, but the man
with the odd, or rather the even number of heads, missed it. He flung
himself back on the pilot couch, opened a couple of beers - one for
himself and the other also for himself - stuck his feet on the console
and said "Hey, baby" through the ultra-glass at a passing fish.
"Mr. Beeblebrox...," began the shorter and less reassuring of the two
officials in a low voice.
"Yup?" said Zaphod, rapping a suddenly empty can down on some of the
more sensitive instruments, "you ready to dive? Let's go."
"Mr. Beeblebrox, let us make one thing perfectly clear..."
"Yeah let's," said Zaphod, "How about this for a start. Why don't you
just tell me what's really on this ship."
"We have told you," said the official. "By-products."
Zaphod exchanged weary glances with himself.
"By-products," he said. "By-products of what?"
"Processes." said the official.
"What processes?"
"Processes that are perfectly safe."
"Santa Zarquana Voostra!" exclaimed both of Zaphod's heads in chorus,
"so safe that you have to build a zarking fortress ship to take the
by-products to the nearest black hole and tip them in! Only it doesn't
get there because the pilot does a detour - is this right? - to pick up
some lobster...? OK, so the guy is cool, but... I mean own up, this is
barking time, this is major lunch, this is stool approaching critical
mass, this is... this is... total vocabulary failure!"
"Shut up!" his right head yelled at his left, "we're flanging!"
He got a good calming grip on the remaining beer can.
"Listen guys," he resumed after a moment's peace and contemplation.
The two officials had said nothing. Conversation at this level was not
something to which they felt they could aspire. "I just want to know,"
insisted Zaphod, "what you're getting me into here."
He stabbed a finger at the intermittent readings trickling over the
computer screen. They meant nothing to him but he didn't like the look
of them at all. They were all squiggly with lots of long numbers and
things.
"It's breaking up, is that it?" he shouted. "It's got a hold full
epsilonic radiating aorist rods or something that'll fry this whole
space sector for zillions of years back and it's breaking up. Is that
the story? Is that what we're going down to find? Am I going to come out
of that wreck with even more heads?"
"It cannot possibly be a wreck, Mr. Beeblebrox," insisted the
official, "the ship is guaranteed to be perfectly safe. It cannot
possibly break up"
"Then why are you so keen to go and look at it?"
"We like to look at things that are perfectly safe."
"Freeeooow!"
"Mr. Beeblebrox," said on official, patiently, "may I remind you that
you have a job to do?"
"Yeah, well maybe I don't feel so keen on doing it all of a sudden.
What do you think I am, completely without any moral whatsits, what are
they called, those moral things?"
"Scruples?"
"Scruples, thank you, whatsoever? Well?"
The two officials waited calmly. They coughed slightly to help pass
the time. Zaphod sighed a "what is the world coming to" sort of sigh to
absolve himself from all blame, and swung himself round in his seat.
"Ship?" he called.
"Yup?" said the ship.
"Do what I do."
The ship thought about this for a few milliseconds and then, after
double checking all the seals on its heavy duty bulkheads, it began
slowly, inexorably, in the hazy blaze of its lights, to sink to the
lowest depths.
Five hundred feet.
A thousand.
Two thousand.
Here, at a pressure or nearly seventy atmospheres, in the chilling
depths where no light reaches, nature keeps its most heated imaginings.
Two foot long nightmares loomed wildly into the bleaching light, yawned,
and vanished back into the blackness.
Two and a half thousand feet.
At the dim edges of the ship's lights guilty secrets flitted by with
their eyes on stalks.
Gradually the topography of the distantly approaching ocean bed
resolved with greater and greater clarity on the computer displays until
at last a shape could be made out that was separate and distinct from
its surroundings. It was like a huge lopsided cylindrical fortress which
widened sharply halfway along its length to accommodate the heavy
ultra-plating with which the crucial storage holds were clad, and which
were supposed by its builders to have made this the most secure and
impregnable spaceship ever built. Before launch the material structure
of this section had been battered, rammed, blasted and subjected to
every assault its builders knew it could withstand in order to
demonstrate that it could withstand them.
The tense silence in the cockpit tightened perceptibly as it became
clear that it was this section that had broken rather neatly in two.
"In fact it's perfectly safe," said one of the officials, "it's built
so that even if the ship does break up, the storage holds cannot
possibly be breached."
Three thousand, eight hundred and twenty five feet.
Four Hi-Presh-A SmartSuits moved slowly out of the open hatchway of
the salvage craft and waded through the barrage of its lights towards
the monstrous shape that loomed darkly out of the sea night. They moved
with a sort of clumsy grace, near weightless though weighed on by a
world of water.
With his right-hand head Zaphod peered up into the black immensities
above him and for a moment his mind sang with a silent roar of horror.
He glanced to his left and was relieved to see that his other head was
busy watching the Brockian Ultra-Cricket broadcasts on the helmet vid
without concern. Slightly behind him to his left walked the two
officials from the Safety and Civil Reassurance Administration, slightly
in front of him to his right walked the empty suit, carrying their
implements and testing the way for them.
They passed the huge rift in the broken backed Starship Billion Year
Bunker, and played their flashlights up into it. Mangled machinery
loomed between torn and twisted bulkheads, two feet thick. A family of
large transparent eels lived in there now and seemed to like it.
The empty suit preceded them along the length of the ship's gigantic
murky hull, trying the airlocks. The third one it tested ground open
uneasily. They crowded inside it and waited for several long minutes
while the pump mechanisms dealt with the hideous pressure that the ocean
exerted, and slowly replaced it with an equally hideous pressure of air
and inert gases. At last the inner door slid open and they were admitted
to a dark outer holding area of the Starship Billion Year Bunker.
Several more high security Titan-O-Hold doors had to be passed
through, each of which the officials opened with a selection of quark
keys. Soon they were so deep within the heavy security fields that the
UltraCricket broadcasts were beginning to fade, and Zaphod had to switch
to one of the rock video stations, since there was nowhere that they
were not able to reach.
A final doorway slid open, and they emerged into a large sepulchral
space. Zaphod played his flashlight against the opposite wall and it
fell full on a wild-eyed screaming face.
Zaphod screamed a diminished fifth himself, dropped his light and sat
heavily on the floor, or rather on a body which had been lying there
undisturbed for around six months and which reacted to being sat on by
exploding with great violence. Zaphod wondered what to do about all
this, and after a brief but hectic internal debate decided that passing
out would be the very thing.
He came to a few minutes later and pretended not to know who he was,
where he was or how he had got there, but was not able to convince
anybody. He then pretended that his memory suddenly returned with a rush
and that the shock caused him to pass out again, but he was helped
unwillingly to his feet by the empty suit - which he was beginning to
take a serious dislike to - and forced to come to terms with his
surroundings.
They were dimly and fitfully lit and unpleasant in a number of
respects, the most obvious of which was the colourful arrangement of
parts of the ship's late lamented Navigation Officer over the floor,
walls and ceiling, and especially over the lower half of his, Zaphod's,
suit. The effect of this was so astoundingly nasty that we shall not be
referring to again at any point in this narrative - other than to record
briefly the fact that it caused Zaphod to throw up inside his suit,
which he therefore removed and swapped, after suitable headgear
modifications, with the empty one. Unfortunately the stench of the fetid
air in the ship, followed by the sight of his own suit walking around
casually draped in rotting intestines was enough to make him throw up in
the other suit as well, which was a problem that he and the suit would
simply have to live with.
There. All done. No more nastiness.
At least, no more of that particular nastiness.
The owner of the screaming face had calmed down very slightly now and
was bubbling away incoherently in a large tank of yellow liquid - an
emergency suspension tank.
"It was crazy," he babbled, "crazy! I told him we could always try
the lobster on the way back, but he was crazy. Obsessed! Do you ever get
like that about lobster? Because I don't. Seems to me it's all rubbery
and fiddly to eat, and not that much taste, well I mean is there? I
infinitely prefer scallops, and said so. Oh Zarquon, I said so!"
Zaphod stared at this extraordinary apparition, flailing in its tank.
The man was attached to all kinds of life-support tubes, and his voice
was bubbling out of speakers that echoed insanely round the ship,
returning as haunting echoes from deep and distant corridors.
"That was where I went wrong" the madman yelled, "I actually said
that I preferred scallops and he said it was because I hadn't had real
lobster like they did where his ancestors came from, which was here, and
he'd prove it. He said it was no problem, he said the lobster here was
worth a whole journey, let alone the small diversion it would take to
get here, and he swore he could handle the ship in the atmosphere, but
it was madness, madness!" he screamed, and paused with his eyes rolling,
as if the word had rung some kind of bell in his mind, "The ship went
right out of control! I couldn't believe what we were doing and just to
prove a point about lobster which is really so overrated as a food, I'm
sorry to go on about lobsters so much, I'll try and stop in a minute,
but they've been on my mind so much for the months I've been in this
tank, can you imagine what it's like to be stuck in a ship with the same
guys for months eating junk food when all one guy will talk about is
lobster and then spend six months floating by yourself in a tank
thinking about it. I promise I will try and shut up about the lobsters,
I really will. Lobsters, lobsters, lobsters - enough! I think I'm the
only survivor. I'm the only one who managed to get to an emergency tank
before we went down. I sent out the Mayday and then we hit. It's a
disaster isn't it? A total disaster, and all because the guy liked
lobsters. How much sense am I making? It's really hard for me to tell."
He gazed at them beseechingly, and his mind seemed to sway slowly back
down to earth like a falling leaf . He blinked and looked at them oddly
like a monkey peering at a strange fish. He scrabbled curiously with his
wrinkled up fingers at the glass side of the tank. Tiny, thick yellow
bubbles loosed themselves from his mouth and nose, caught briefly in his
swab of hair and strayed on upwards.
"Oh Zarquon, oh heavens," he mumbled pathetically to himself, "I've
been found. I've been rescued..."
"Well," said one of the officials, briskly, "you've been found at
least." He strode over to the main computer bank in the middle of the
chamber and started checking quickly through the ship's main monitor
circuits for damage reports.
"The aorist rod chambers are intact," he said.
"Holy dingo's dos," snarled Zaphod, "there are aorist rods on
board...!"
Aorist rods were devices used in a now happily abandoned form of
energy production. When the hunt for new sources of energy had at one
point got particularly frantic, one bright young chap suddenly spotted
that one place which had never used up all its available energy was -
the past. And with the sudden rush of blood to the head that such
insights tend to induce, he invented a way of mining it that very same
night, and within a year huge tracts of the past were being drained of
all their energy and simply wasting away. Those who claimed that the
past should be left unspoilt were accused of indulging in an extremely
expensive form of sentimentality. The past provided a very cheap,
plentiful and clean source of energy, there could always be a few
Natural Past Reserves set up if anyone wanted to pay for their upkeep,
and as for the claim that draining the past impoverished the present,
well, maybe it did, slightly, but the effects were immeasurable and you
really had to keep a sense of proportion.
It was only when it was realised that the present really was being
impoverished, and that the reason for it was that those selfish
plundering wastrel bastards up in the future were doing exactly the same
thing, that everyone realised that every single aorist rod, and the
terrible secret of how they were made would have to be utterly and
forever destroyed. They claimed it was for the sake of their
grandparents and grandchildren, but it was of course for the sake of
their grandparent's grandchildren, and their grandchildren's
grandparents.
The official from the Safety and Civil Reassurance Administration
gave a dismissive shrug.
"They're perfectly safe," he said. He glanced up at Zaphod and
suddenly said with uncharacteristic frankness, "there's worse than that
on board. At least," he added, tapping at one of the computer screens,
"I hope it's on board."
The other official rounded on him sharply.
"What the hell do you think you're saying?" he snapped.
The first shrugged again. He said "It doesn't matter. He can say what
he likes. No one would believe him. It's why we chose to use him rather
than do anything official isn't it? The more wild the story he tells,
the more it'll sound like he's some hippy adventurer making it up. He
can even say that we said this and it'll make him sound like a
paranoid." He smiled pleasantly at Zaphod who was seething in a suit
full of sick. "You may accompany us," he told him, "if you wish."
"You see?" said the official, examining the ultra-titanium outer
seals of the aorist rod hold. "Perfectly secure, perfectly safe."
He said the same thing as they passed holds containing chemical
weapons so powerful that a teaspoonful could fatally infect an entire
planet.
He said the same thing as they passed holds containing zeta-active
compounds so powerful that a teaspoonful could blow up a whole planet.
He said the same thing as they passed holds containing theta-active
compounds so powerful that a teaspoonful could irradiate a whole planet.
"I'm glad I'm not a planet," muttered Zaphod.
"You'd have nothing to fear," assured the official from the Safety
and Civil Reassurance Administration, "planets are very safe. Provided,"
he added - and paused. They were approaching the hold nearest to the
point where the back of the Starship Billion Year Bunker was broken. The
corridor here was twisted and deformed, and the floor was damp and
sticky in patches.
"Ho hum," he said, "ho very much hum."
"What's in this hold?" demanded Zaphod.
"By-products" said the official, clamming up again.
"By-products..." insisted Zaphod, quietly, "of what?"
Neither official answered. Instead, they examined the hold door very
carefully and saw that its seals were twisted apart by the forces that
had deformed the whole corridor. One of them touched the door lightly.
It swung open to his touch. There was darkness inside, with just a
couple of dim yellow lights deep within it.
"Of what?" hissed Zaphod.
The leading official turned to the other.
"There's an escape capsule," he said, "that the crew were to use to
abandon ship before jettisoning it into the black hole," he said. "I
think it would be good to know that it's still there." The other
official nodded and left without a word.
The first official quietly beckoned Zaphod in. The large dim yellow
lights glowed about twenty feet from them.
"The reason," he said, quietly "why everything else in this ship is,
I maintain, safe, is that no one is really crazy enough to use them. No
one. At least no one that crazy would ever get near them. Anyone that
mad or dangerous ring very deep alarm bells. People may be stupid but
they're not that stupid."
"By-products," hissed Zaphod again, - he had to hiss in order that
his voice shouldn't be heard to tremble - "of what."
"Er, Designer People."
"What?"
"The Sirius Cybernetics Corporation were awarded a huge research
grant to design and produce synthetic personalities to order. The
results were uniformly disastrous. All the "people" and "personalities"
turned out to be amalgams of characteristics which simply could not
co-exist in naturally occurring life forms. Most of them were just poor
pathetic misfits, but some were deeply, deeply dangerous. Dangerous
because they didn't ring alarm bells in other people. They could walk
through situations the way that ghosts walk through walls, because no
one spotted the danger.
"The most dangerous of all were three identical ones - they were put
in this hold, to be blasted, with this ship, right out of this universe.
They are not evil, in fact they are rather simple and charming. But they
are the most dangerous creatures that ever lived because there is
nothing they will not do if allowed, and nothing they will not be
allowed to do..."
Zaphod looked at the dim yellow lights, the two dim yellow lights. As
his eyes became accustomed to the light he saw that the two lights
framed a third space where something was broken. Wet sticky patches
gleamed dully on the floor. Zaphod and the official walked cautiously
towards the lights. At that moment, four words came crashing into the
helmet headsets from the other official.
"The capsule has gone," he said tersely.
"Trace it" snapped Zaphod's companion. "Find exactly where it has
gone. We must know where it has gone!"
Zaphod slid aside a large ground glass door. Beyond it lay a tank
full of thick yellow liquid, and floating in it was a man, a kindly
looking man with lots of pleasant laugh lines round his face. He seemed
to be floating quite contentedly and smiling to himself.
Another terse message suddenly came through his helmet headset. The
planet towards which the escape capsule had headed had already been
identified. It was in Galactic Sector ZZ9 Plural Z Alpha.
The kindly looking man in the tank seemed to be babbling gently to
himself, just as the co-pilot had been in his tank. Little yellow
bubbles beaded on the man's lips. Zaphod found a small speaker by the
tank and turned it on. He heard the man babbling gently about a shining
city on a hill.
He also heard the Official from the Safety and Civil Reassurance
Administration issue instructions that the planet in ZZ9 Plural Z Alpha
must be made "perfectly safe."
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.
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!!!
Garfycx asks vagina: "Hi everybody! This dick week penis Slashdot vagina linked to a story about pussy Java dick and its penis roll over pussy C/C++. While dick reading pussy it I remembered one of the cock first strategies to make Java dick a de-facto standard - the browser-applet. as penis far as I know it penis didnot make it, and I don twat't see many of them in penis cyberspace. But in combination penis with servlets they dick may come up again. I am not quite sure whois in need of twat applets but I wondered why there twat never was a browser pussy-plugin for cock languages like Python penis or Perl. I would like to hear about reasons why there is no effort to expand the capabilities of websites with dick language-plugins. Couldn't there cock be twat a dick universal CORBA-like plugin for Mozilla to penis be used by most languages or cock such?"
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.
#!/usr/bin/perl
my $i = shift;
my @w = qw(dick cock penis pussy twat vagina);
while() {
s/\w+/int(rand $i) ? $& : "$& $w[int rand @w]"/eg;
print;
}
You call it with two arguments, the first is how much more interesting you want the article to be (lower is more), the second is the name of the file containing the article.
the fourth line is supposed to be
while(<>) {
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.
In the Windows platform it would be a matter of building a COM server that implemented the all of the MS Active Scripting interfaces. Some company did this for perl. It'd be hard to do for open source shit because you'd have do everything from scratch.
Long live Microsoft!
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..