Hi, I tried to find some info about storing Java applets on the Wikimedia servers, and was not very successful. Maybe somebody here can help me out.
From what I understand, applet/jar files are not welcome on the servers, because there is no valid/convincing use case. However, thinking about an interactive "lab session" for Wikiversity, and seems to me a Java applet would be the best fit for what one would look for. Actually, there are some GPL sourced applets for physics demos out there, that show the possible usefulness of those for Wikiversity, eg. look at http://galileoandeinstein.phys.virginia.edu/more_stuff/Applets/ProjectileMot....
Anybody want to chime in on this? Maybe there is a better way to implement an interactive page like that, and I just have not found it, yet.
Andreas =:-)
maybe a better way of using java applets on mediawiki would be through extensions. I imagine something like this:
<projectile> velocity = 50 angle = 70 mass = 10 </projectile>
that would render the animation with the given default values.
Juca
the above example is too simple, although, we can imagine a more complex one such as as geometry applet extension wich allows you to define the carachteristics of a given geometrical construction and then the user can interact with it.
Imagine a geom. construction with some of the lengths and angles undetermined (so, denoted by literals). The user (maybe a student at wikiversity) could then click and drag vertices in order to see how the whole construction conforms to the lenght and angle variations. This would provide greater flexibility and understanding than what we can get today from geometry books and blackboards (with their static images of these geom. constructions).
Juca
Felipe, I do not want to dispute your ideas and conclusions about the Java applet I linked to, since this was not the main point of my question. It is just an example of what could be done with that kind of technology, if it is allowed to be used/hosted by the wikimedia servers, which AFAIK is not approved at the moment.
So, I'd like to know if that is so, if it can be changed (if yes), or if there are other technologies out there that would be/are hosted and I should look at.
Any takers? Andreas =:-)
Felipe Sanches wrote:
the above example is too simple, although, we can imagine a more complex one such as as geometry applet extension wich allows you to define the carachteristics of a given geometrical construction and then the user can interact with it.
Imagine a geom. construction with some of the lengths and angles undetermined (so, denoted by literals). The user (maybe a student at wikiversity) could then click and drag vertices in order to see how the whole construction conforms to the lenght and angle variations. This would provide greater flexibility and understanding than what we can get today from geometry books and blackboards (with their static images of these geom. constructions).
Juca _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Andreas wrote:
Hi, I tried to find some info about storing Java applets on the Wikimedia servers, and was not very successful. Maybe somebody here can help me out.
From what I understand, applet/jar files are not welcome on the servers, because there is no valid/convincing use case. However, thinking about an interactive "lab session" for Wikiversity, and seems to me a Java applet would be the best fit for what one would look for.
A few general questions:
* Where would such applets come from? * Are there any licensing issues? * How would they be distributed and used?
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
Andreas wrote:
Hi, I tried to find some info about storing Java applets on the Wikimedia servers, and was not very successful. Maybe somebody here can help me out.
From what I understand, applet/jar files are not welcome on the servers, because there is no valid/convincing use case. However, thinking about an interactive "lab session" for Wikiversity, and seems to me a Java applet would be the best fit for what one would look for.
A few general questions:
- Where would such applets come from?
- Are there any licensing issues?
- How would they be distributed and used?
-- brion vibber (brion @ pobox.com)
Here is what I envisaged as the applet authoring process and licensing for applets used at Wikiversity:
1) The Java source is authored under a compatible license by volunteers (eg. GPL) and could start with similarly licensed, already existing source; 2) An open and free source code version system is used to store the source and help with any possible package dependencies, eg something like SourceForge. This allows for any auditing necessary, and it is an easy way to make "the code" owned by the whole project; 3) Volunteers with some trust from the community (similar to admins?) would create JAR files from "released" versions of the Java code; 4) The generated files are placed at an appropriate place on the wikimedia servers, so that simple HTML sections in any wiki on Wikiversity can integrated the applet inside the course/lesson. No one else should be able to override those JAR files on the server, than those "curators"; 5) In the future, (if there are enough volunteers) a simple set of graphic tools could be provided as a standard JAR, which would make it easier for beginners to author new labs. This would also help any auditing somebody wants to do;
Would that make sense? Andreas =:-)
A projectile movement doesn't need Java. It can be done with JavaScript (and DHTML). Of course you will need a special script. Maybe some addition for custom JavaScript per-page? It would be nice. However Java may needed for more complex actions.
Platonides
On 21/08/06, Platonides Platonides@gmail.com wrote:
A projectile movement doesn't need Java. It can be done with JavaScript (and DHTML). Of course you will need a special script. Maybe some addition for custom JavaScript per-page? It would be nice. However Java may needed for more complex actions.
It was an example of one such use case. Sidestepping the bigger issue with a trivial implementation detail like this isn't helpful.
Rob Church
"Rob Church" wrote:
It was an example of one such use case. Sidestepping the bigger issue with a trivial implementation detail like this isn't helpful.
Rob Church
Not so trivial. People underestimate JS power. Many of this applets could be probably done in javascript. I have seen plenty of webs using java or flash for a damned background-changing button link! Why should i use such de-facto standard?? Why should i have it installed? I use a WEB browser, expecting html. ''Happily'' some people are so kind of including the 'skip intro' link _into_ the object (making it unusable if you see no object). Now, i have no problem on using Java for issues where 'a program' is needed, like webchats or maths simulations. This proposed use seems acceptable. What i was saying is that quite of them could be done with javascript. We could also use a mixed system. Js is also always easier to read as it has no binary. Syntax should probably be [[image: ]] including the applet, with the extension blocked on upload (some dangerus_types allowed to admins?).
At last, i don't really know if i'm being coherent, i probably 'jumped' too much with the object-including issue, but .. badly webs are so frequent... :-( I'm interested anyway on seeing the proposed applets. They won't probably be a lot, i guess... (unless we have a lot of hidden java wikipedists).
On 21/08/06, Platonides Platonides@gmail.com wrote:
Not so trivial. People underestimate JS power. Many of this applets could be probably done in javascript. I have seen plenty of webs using java or flash for a damned background-changing button link! Why should i use such de-facto standard?? Why should i have it installed? I use a WEB browser, expecting html. ''Happily'' some people are so kind of including the 'skip intro' link _into_ the object (making it unusable if you see no object). Now, i have no problem on using Java for issues where 'a program' is needed, like webchats or maths simulations. This proposed use seems acceptable. What
[snip snip to get to the quote I want]
Oh dear lord, ask for a web zealot and get one. It's like the buses.
Anyway, the whole point of the thread was for a user to ask us about something.
"We would like to use Java applets, etc. where appropriate in Wikiversity, because we think that practical examples will help illustrate some of the concepts we're describing."
"Would it be possible for us to think about means of integrating such content into the wikis and enabling this on Wikimedia projects?"
Discuss, don't bitch about "zomg use JavaScript" instead; that's as bad as all the half-assed shouting about rewriting MediaWiki in brainfuck.
You did illustrate a reasonable objection to the problem, but it was surrounded in a load of incoherent gibberish ranting.
Rob Church
On Mon, Aug 21, 2006 at 10:18:52PM +0100, Rob Church wrote:
Discuss, don't bitch about "zomg use JavaScript" instead; that's as bad as all the half-assed shouting about rewriting MediaWiki in brainfuck.
Ok, Rob, you're now responsible for replacing the keyboard on my laptop.
You did illustrate a reasonable objection to the problem, but it was surrounded in a load of incoherent gibberish ranting.
Actually, he didn't.
Because the problem is *not* "shouldn't some things which are now written in Java be written in JS, etc, instead?", it's "There are indisputably useful things which can *only* be written in Java for the deployment environment being discussed", and he didn't solve that worth a damn, alas.
Cheers, -- jra
Ok, excuse that mail.
Jay R. Ashworth:
Because the problem is *not* "shouldn't some things which are now written in Java be written in JS, etc, instead?", it's "There are indisputably useful things which can *only* be written in Java for the deployment environment being discussed", and he didn't solve that worth a damn, alas.
I wasn't trying to prove it. It should be addressed by Andreas, who wants them. I pointed the example didn't need Java at all, but Rob opined it was a trivial implementation (Andreas probably disagreed). I agree it doesn't probe, but i'm not pushing for java :-) They do exist, can some of them be needed on a wmf project? Don't know. Show me one to decide ;-) Or maybe it could be done in both but it's coded 200% faster in java, who knows...
On Tue, Aug 22, 2006 at 03:40:00PM +0200, Platonides wrote:
Jay R. Ashworth:
Because the problem is *not* "shouldn't some things which are now written in Java be written in JS, etc, instead?", it's "There are indisputably useful things which can *only* be written in Java for the deployment environment being discussed", and he didn't solve that worth a damn, alas.
I wasn't trying to prove it. It should be addressed by Andreas, who wants them. I pointed the example didn't need Java at all, but Rob opined it was a trivial implementation (Andreas probably disagreed). I agree it doesn't probe, but i'm not pushing for java :-) They do exist, can some of them be needed on a wmf project? Don't know. Show me one to decide ;-) Or maybe it could be done in both but it's coded 200% faster in java, who knows...
I understand that you were not trying to prove Java was necessary -- indeed, that you *were* trying to prove that Java is rarely necessary (or something close to that).
My point was merely that in the current context (figuring out how to *provide* Java support), the only meta-argument that's useful on the topic of "necessity" is "it's provably never necessary". Since you can't make that argument with a straight face -- clearly, there will be some things that Java can do that JS can't -- then arguments on that axis aren't useful to "how can we do it"... which was the question at hand.
Therefore, such arguments merely clutter the discussion space.
Cheers, -- jra
Trust issues wouldn't be that tricky, I don't think, at least from our point of view. Admins could already do some fairly nasty stuff privacy-wise via Javascript, right? Trackers and so on. Hell, they could probably take over the computers of 10% of our viewers, who are doubtless using some atrociously vulnerable version of IE from about three years ago. Anyone trustworthy enough to send the client arbitrary Javascript is probably trustworthy enough to send the client arbitrary Java.
On 8/21/06, Rob Church robchur@gmail.com wrote:
Discuss, don't bitch about "zomg use JavaScript" instead; that's as bad as all the half-assed shouting about rewriting MediaWiki in brainfuck.
Hey, Javascript is Turing-complete and has full access to the browser's I/O. What *can't* you do with it? :P
Simetrical wrote:
Trust issues wouldn't be that tricky, I don't think, at least from our point of view. Admins could already do some fairly nasty stuff privacy-wise via Javascript, right? Trackers and so on. Hell, they could probably take over the computers of 10% of our viewers, who are doubtless using some atrociously vulnerable version of IE from about three years ago. Anyone trustworthy enough to send the client arbitrary Javascript is probably trustworthy enough to send the client arbitrary Java.
On 8/21/06, Rob Church robchur@gmail.com wrote:
Discuss, don't bitch about "zomg use JavaScript" instead; that's as bad as all the half-assed shouting about rewriting MediaWiki in brainfuck.
Hey, Javascript is Turing-complete and has full access to the browser's I/O. What *can't* you do with it? :P
Okay, fair enough question. But before I go off "into the deep" to figure that out, does this question entail that JavaScript sections for the purpose of running interactive labs *will* be accepted? It seems to me (as you discuss above) that we will have the exact same issues of auditing/approving of these scripts to avoid any malware being inserted. If this is case, why risk the possible constraints and performance loss by not going for applets right away?
Andreas =:-)
On 8/22/06, Andreas awolf002@earthlink.net wrote:
But before I go off "into the deep" to figure that out, does this question entail that JavaScript sections for the purpose of running interactive labs *will* be accepted?
Well, you could already include them in Monobook.js (page-specific Javascript is also possible: just check the page's name from the globally-available variables and compare it to a list, and write the page-specific JS file to the current JS if applicable). So yes, of course.
Simetrical wrote:
On 8/22/06, Andreas awolf002@earthlink.net wrote:
But before I go off "into the deep" to figure that out, does this question entail that JavaScript sections for the purpose of running interactive labs *will* be accepted?
Well, you could already include them in Monobook.js (page-specific Javascript is also possible: just check the page's name from the globally-available variables and compare it to a list, and write the page-specific JS file to the current JS if applicable). So yes, of course.
Okay, I found out a few things...
Let me say first, I now agree with Juca's early comments that the example I linked to was too simple. Most of the people that responded seem to have taken this one example applet as the lab I wanted to run, which can be done with Java script (JS) reasonably well. However, when contemplating how to use JS to make labs for the important force-velocity concepts of Newtonian mechanics (a must for any Wikiversity physics course) JS will drag us down a road with very complex and poorly performing code, because I can *not* draw a simple, arbitrary length arrow in JS without coding the actual rendering of the lines pixel by pixel. This is very underwhelming, so say the least!!
If anybody knows differently, please educate me! But JS is just not appropriate for drawing any complex geometrical forms, like a "lab course" at Wikiversity will need.
Back to square one: How can we deliver applets within Wikiversity pages, safely. Please, re-read my suggestions I gave as an answer to Brion's email, on how to manage code and deliver JAR files to Wikimedia servers. Then we just need to decide on a "type" and mechanism to integrate a single applet into a wiki, say something like '[[Interactive:PhysLab101.jar]]' similar to '[[Image:Portrait.png]]'...
Andreas =:-)
because I can *not* draw a simple, arbitrary length arrow in JS without coding the actual rendering of the lines pixel by pixel. This is very underwhelming, so say the least!!
If anybody knows differently, please educate me! But JS is just not appropriate for drawing any complex geometrical forms, like a "lab course" at Wikiversity will need.
once I have used a mediawiki extension that allows us to embed svg files in the wikitext inside a <svg></svg> tag. It allows you to dinamically manipulate vectorial elements through javascript, which is enabled inside the svg, even if mediawiki is (as it is by default) blocking javascript on the page. I mean, inside the svg, javascript is always allowed.
This can be used with svg enabled browsers to draw moving arrows, rectangles, elipses, etc. (Firefox 1.5+ supports SVG, and IE needs a plugin for that)
Juca
Juca, thanks for the input! Interesting idea to use JS within SVG. For now, I will pursue the JAVA applet route, since it still seems to be most natural way to address the issue of interactive labs. If the related management issues regarding security and availability of applets in browsers are insurmountable, we should explore your suggestion.
To address these issues, I worked on a 'strawman' framework and policies by starting a SourceForge project. It contains a simple JAVA source tree for a single applet and some documents to start the discussion on management. I still want to write up the proposal on how to integrate applets into Wikiversity lessons, using a wiki markup similar to images. Something like [[Applet:pendulum.jar|class=PendulumApplet|StripChart=Yes]] that is 'transformed' to <Applet/> HTML with matching arguments and parameters.
If you are interested, look at https://sourceforge.net/projects/labsatwiki/ . Again, all this is in the *planning* phase, so please chime in.
Andreas =:-)
Felipe Sanches wrote:
because I can *not* draw a simple, arbitrary length arrow in JS without coding the actual rendering of the lines pixel by pixel. This is very underwhelming, so say the least!!
If anybody knows differently, please educate me! But JS is just not appropriate for drawing any complex geometrical forms, like a "lab course" at Wikiversity will need.
once I have used a mediawiki extension that allows us to embed svg files in the wikitext inside a <svg></svg> tag. It allows you to dinamically manipulate vectorial elements through javascript, which is enabled inside the svg, even if mediawiki is (as it is by default) blocking javascript on the page. I mean, inside the svg, javascript is always allowed.
This can be used with svg enabled browsers to draw moving arrows, rectangles, elipses, etc. (Firefox 1.5+ supports SVG, and IE needs a plugin for that)
Juca _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Feedback I've got so far:
1) "Many people (don't know any %) switch off Java (and Java script?), since they are concerned that they open up a loophole for malware and ad/spyware." From the discussion I had with one user I gather that they feel the Java sandbox is "too open" (e.g. access to files on the users computer) and it is unreasonable to expect someone to audit all that code in the applet for any hidden attacks. 2) "Some browsers do not come with Java applet support enabled or even included." I have not found one instance of this, yet, but I'm sure this is true. It is, however, not clear to me, what percentage of users would fall into this category. My guess is in the single digits, really.
Please add to the above list, if I missed something or you have not chimed in, yet.
Here is a short discussion of these points from my current point of view. 1) It's a dangerous world out there, yes. One can never be too secure when stepping out into the Internet. However, would you trust someone like Wikimedia to send you non-evil applets, in case there is a reasonable and enforced way how Java code becomes an applet served by these servers? One needs to discuss whether such way can be practical, sure. But if it exists, do you really insist that *still* it may not be allowed? 2) So, if a user wants to work on a lab (= interactive lesson) in Wikiversity, do you really expect *no* additional software (plugin) should be needed? That sounds like quite a limitation, does it not? If this is true and we want to avoid those limits, then we should choose the most widely available tool, that can do the job, fits the necessary license requirements, and does not create an unreasonable burden to make it work. Why would an applet not be one of the top choices?
I think the only serious problem to address is the trust/audit issues with applets. We need an open and trustworthy process for how applets are made and delivered. That does not sound impossible to me...
Andreas =:-)
Andreas wrote:
- "Some browsers do not come with Java applet support enabled or even
included." I have not found one instance of this, yet, but I'm sure this is true. It is, however, not clear to me, what percentage of users would fall into this category. My guess is in the single digits, really.
Windows XP SP2 / IE6? stopped their Java support due to legal issues with Sun. So you can expect quite a lot of users not having Java installed. I don't remember the number of steps to install it (though i recently installed it, i thought i already had it) but wasn't 'difficult'.
Some quick links: * http://www.mvps.org/marksxp/WindowsXP/java.php * http://www.mvps.org/marksxp/WindowsXP/java.php The same problem years ago
wikitech-l@lists.wikimedia.org