CZ:Proposals/New: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Audrius Meskauskas
No edit summary
imported>Audrius Meskauskas
(not here)
Line 33: Line 33:
}}
}}


== Add Java applet support ==
{{proposal
{{proposal
|Brief descriptive title = Java applet support
|Brief descriptive title = Java applet support
Line 42: Line 43:
|Notes =   
|Notes =   
}}
}}
Java applet is a powerful feature to illustrate mathematical, technical, electric and some other subjects, from interactive function graphs till mathematical models with advanced visualization. Unlike animations, they may have controls to interact with the user, allowing active experiments. They are fast enough for non trivial visualizations that are computation intensive. They are more portable, secure and website-integrable than standalone applications. During the years, lots of applets were created for educational and similar purposes; it is even possible to suspect that this is one of the most successful areas of they use. Some scientific projects have applets as an illustrations of concepts, discovered during research work.
Java applets are also [http://strategy.wikimedia.org/wiki/Proposal:Java_applet_support proposed for Wikipedia] by the same author, with quite a discussion evolving around. However Citizendium Citizendium users are real users with real names, making applet usage far easier here:
* It looks more acceptable here that some complex piece of illustrative material (like Java applet) can only be written and maintained by a specialist. Wikipedia, differently, much stronger follows the rule that "anyone can edit" and many talks against advanced visualization are based on claims that not everybody can program, not everybody has suitable computer to install development environment and so on.
* Also, it seems more acceptable here that applet has a maintainer, a person with real name that updates and expands it, so it may not be necessary to start from the difficult to implement changes as the public code review or the forced server side compilation of all provided applets. An applet must fulfill licensing rules in a compiled role, serving its content same way as image does. From the other side I am not against requiring the applet source code to be under FOSS license and would support this idea.
* Unlike in Wikipedia, the level of vandalism is extremely low (if not zero). This makes highly unlikely that somebody will start exercising a vandalism so difficult as uploading potentially malicious applets. As Java applets run in a sandbox (no access to the local filesystem, clipboard, etc) and can only talk with the host where it has been downloaded from, security risks may not be actually so huge. The author of this proposal is convinced that big part of talks about Java insecurity is an urban legend as applets are even more restricted than currently abundant JavaScript
It is a normal security practice to disable all unneeded browser features for untrusted sites, and it may happen that Java is disabled by default as well on a majority of browsers. This, however, does not look like a major problem as it is not complex to install1 and enable Java for selected sites. Administrators are also not just devils: after several years of nothing horrible happening around they would enable features that people need for they direct work. Hence general argument that "Java will not run because it is disabled" may also not be universal.
Java is a highly popular language with long history; many issues that were possible in the past should be resolved. Educational and demonstrational Java applets are abundant on a web, showing that this technology may be efficient and attractive. Not all they are under FOSS licenses, but many are, showing the willingness of some authors to share the work. Allowing applets would allow Java developers to participate in Wikipedia with they programming contribution. For the average developer, writing applet is relatively very easy task, comparable by time with the text contribution and producing much more valuable output.

Revision as of 05:42, 30 September 2009

Instructions

To start a new proposal or issue, simply click this edit link - it is recommended that you right-click the link, and select 'open in new window' to open it in a new window, so that you can continue to be able to read the instructions here in the old window. That link will provide an edit window containing a blank copy of the template which needs to be filled out in order to create a new proposal section here. Enter the details in the template, using the instructions below, and press save! That's it — it's very easy.

Here's how to fill it out:

  1. Brief descriptive title. Make this brief, because it will be part of a page title. If you are raising an issue (ask for a decision among two or more options), please word the title as a question. Note: this exact same text goes in the Subject/headline box, too.
  2. Summary of proposal. Limited to 100 words.
  3. Name and date of original proposer: write four tildes ~~~~
  4. Username of driver. If you, write three tildes ~~~; if someone else, specify. This is the person who makes sure the proposal moves along from step to step in its development. If the "driver" is left blank, and no one volunteers to be driver, your proposal may be moved to the "discarded" queue. The driver should get familiar with the proposals system policy page.
  5. Next step. The next thing you need to do to move the proposal toward reality. Not sure what to write? Hints here.
  6. Target date for next step. A date the driver commits to, for completing the next step. If you drop the ball, the proposal may become driverless.
  7. (Optional) Notes. Brief salient remarks. Bear in mind the bulk of the info about the proposal doesn't go here but on the (much bigger) proposal page. A handy link to the proposal page will pop up after you save the template.

Optional next step for proposers. This is optional, and you can leave it to the driver. Follow the "complete proposal" link you'll find at the bottom of your new proposal box. On that page, you can elaborate the proposal or issue, link to pre-existing discussions, and generally say whatever you think needs to be said in order to get the proposal adopted (or the issue decided) and implemented. That's generally where to follow the progress of your proposal. (Guidelines are available.)

New proposals

Looking for your proposal, which used to be here? Check the list of all proposals.

If a proposal here does not have a "driver," it may be moved to the driverless proposals queue a week after being proposed.

Proposals System Navigation (advanced users only)

Proposal lists (some planned pages are still blank):

Extension:FormatDates

Summary: It's very annoying the way some dates on CZ are in UK format (3rd May 2009 or 03/05/2009), some in US format (May 3, 2009 or 05/03/2009), and some in "international" format (2009-05-03). The use of the FormatDates extension (http://www.mediawiki.org/wiki/Extension:FormatDates) would solve this problem.
Original proposer: Caesar Schinas 13:31, 3 May 2009 (UTC) Next step: Fill in next step
Driver: Driver needed (i.e., someone familiar with the proposals system who will move it through the system) To be done by: Fill in target date for next step
To the proposer: please read the proposals system policy page if you want to fill out a complete proposal, not just this summary. If you don't, please ask around for someone (a "driver") to take over your proposal!
Start complete proposal


Add Java applet support

Summary: Allow to upload and use Java applets in articles
Original proposer: Audrius Meskauskas Next step: Implement Wiki language extensions, allowing to embed Java applet into article. Allow to upload .jar files into repository.
Driver: Audrius Meskauskas 11:23, 30 September 2009 (UTC) To be done by: Fill in target date for next step
Complete proposal