Proposal talk:Allow upload of flash animations

Client side scripting

Allowing Flash animations means allowing en:ActionScript, so we actually speak about the client side scripting again. It is important to have this in mind and do not look as into proposal just to upload animations. Audriusa 21:58, 22 August 2009 (UTC)

not feasible

the implications of this proposal are that it will be unacceptable to upload untrusted flash animations, requiring that the source code be uploaded instead.

as the compilers, to turn flash (actionscript) source code into actual .swf files are proprietary, and only available from adobe, those can't be trusted, either.

therefore, outright and simple: this proposal is unworkable. Lkcl 09:12, 15 October 2009 (UTC)

Yes there are free software versions of Flash

... and they're shit. no disrespect to the authors and the incredible work being done behind swfdec and gnash, but the sheer amount of effort required to reverse-engineer these protocols which adobe flatly refuses to publish, citing stupid proprietary advantage, is just absolutely overwhelming. the persistence of the developers, flying in the face of these overwhelming odds against success... i'm just really proud of them and yet, due to the man-decades of time spent already by adobe in developing 10 versions of Flash, the free software developers have only begun to scratch the surface.

• swfdec only supports ActionScript 2 (Flash 8 and below, i believe).
• both gnash and swfdec have different subsets of the complete binary interoperability with .swf files
• there are no decent free software flash development tools, forcing people who would like to edit SWF animations to download and use a large, unwieldy proprietary development platform.

the bottom line is that by allowing flash, you run the risk of creating a nightmare situation for contributors, reviewers, users, editors, and, in fact absolutely everybody. --Lkcl

I like my saying "Flash aint done till Gnash won't run". As you've pointed out flash is effectively proprietary which leads to many problems, not the least of which is the complete lack of availability in reasonable authoring tools. Swfdec and Gnash reduce the bleeding, the unintentional closing of the technologies behind the web… but having a workable tourniquet handy is no excuse to cut yourself.

I think with proposals like this it's best to look at the end goal and look past the technology. What does someone want to accomplish? How can this be accomplished without abandoning open technology? Without locking us into an online audience? Without inhibiting editing? etc. Unfortunately when someone simply proposes "We should use froboz!" it can be difficult to get to the underlying goal "I want to easily add attractive graphs of kind X for purpose Y". --Gmaxwell 14:40, 15 October 2009 (UTC)

The goal of these proposals, all, is to provide interactive content. They offer various means to solve it. The present content is not interactive as it does not change itself in response to the user manipulations - experimentations AudriusA 19:34, 24 December 2009 (UTC).

I recently tested gnash and it runs for me, including pages I needed to access merely to get the required information from them. Some others, however, does not run, including CNN pages. However, in general, gnash seems having not so bad potential. I would prefer to see JavaScript or OpenJDK plugins, however, these have far less proprietary potential. AudriusA 19:34, 24 December 2009 (UTC)

Impact?

Some proposals will have massive impact on end-users, including non-editors. Some will have minimal impact. What will be the impact of this proposal on our end-users? -- Philippe 00:05, 3 September 2009 (UTC)

just as with the java idea, this proposal will have a negative impact on both accessibility and reach, and should be denied, outright. absolutely any idea that proposes that wikipedia information be expressed in a programming language (in this case, ECMAScript 3 aka actionscript aka "flash") will result in:

1. elitism (restriction to those people capable of programming) and thus reduce reach;
2. reduced accessibility (due to some client systems being unable to play the .swf file, for technical, CPU, memory or bandwidth reasons) with the risk that important information may solely and exclusively be expressed in the .swf file not in the associated text
3. increased load on the wikipedia servers due to the need to check the binary formatted .swf file (if that's at all technically possible and practical)
4. increased load on wikipedia volunteers to manually check the binary-formatted .swf file to ensure that it complies with a minimum specification (e.g. SWF 8; ActionScript 2; does not require features that the latest free software flash-compatible player doesn't have).

overall, allowing flash animations, java, silverlight or (sadly, against my own personal preferences, even javascript): allowing anything in fact other than the absolute lowest common denominator of images and text, is an incredibly bad idea, and would, in every case and in every way, shape and form, be directly against the aims of the wikimedia strategy process and the goals of the wikipedia foundation. this cannot be overstated. Lkcl 20:16, 11 October 2009 (UTC)

'"increased load on the wikipedia servers due to the need to check" in the general case you can't automatically determine if a piece of computer software will ever stop running, much less what it will actually do. See w:Halting problem. The upload of binary-form software by random contributors couldn't be permitted for practical reasons: We could never tell what it would do with any degree of confidence using a reasonable amount of effort. Today some binary-swf displays a graph of kitten population growth rates over time, tomorrow it displays shock-images. Or worse— it displays accurate information if you appear to be an established Wikipedia contributor, subtly wrong material if you don't. --Gmaxwell 14:47, 15 October 2009 (UTC)

Merge?

Should probably be merged into Proposal:Better Video. This seems to be a (small) subset of that. ^demon 19:11, 4 September 2009 (UTC)

Alternatives

For information about open source alternatives, see H.263 and players Ffdshow, VLC media player, and MPlayer. Clearly Wikipedia will favor open source free software solutions. Mike Serfas 03:04, 23 September 2009 (UTC)

Video isn't really an alternative for animations. SVG+JS animation of SVG, or simple animation systems created using JS and the canvas tag are example alternatives. --Gmaxwell 14:50, 15 October 2009 (UTC)

Ogg, Java and SVG

And Java (see Proposal talk:Java applet support#JavaFX and Jigsaw). The purpose of flash can be divided into

• movies (better solution is a Ogg)
• computationally complex interactive content (better solution is Java/JavaFX)
• computationally simple interactive content (better solution is SVG with JavaScript interaction)

Last but not least interactivity doesn't seem terribly important for an encyclopedia, at least when the target audience are primarily adults; for a Wikipedia exclusively for Kids interactivity may be more important. --Fasten (Wikinews: Aktion Deutschland Hilft asks for donations after the earthquake in Indonesia) 21:17, 11 October 2009 (UTC)

SVG is only 40% (rough guess) of world's browsers. i.e. you've forgotten IE (pun intended). IE uses VML. so, you have to have an API which maps to SVG or VML. this is technically possible, and has been done many times. see http://excanvas.sf.net for example.

From every angle conceivable, the deployment of java would be immensely detrimental to wikipedia and would be in direct contravention of the goals and aims of the wikipedia foundation. There isn't a single benefit to deployment of java, in a way that ordinary people can use it to contribute to wikipedia pages, that cannot be achieved by other technical means. so - no, java is not acceptable, period. Lkcl 09:16, 15 October 2009 (UTC)

On that there are other opinions as well. AudriusA 10:09, 24 December 2009 (UTC)