Hi Kat Walsh.
Would it be possible for the board to state something to the effect that
using open source code to target proprietary software subcomponents of
propitiatory users software platform in order to provide feature parity
with free software experiences is oky?
We of course already do this to a certain extent with any sub section of
code that is written to only run on IE or Opera as we try to maintain
feature parity for visitors on non-free-software platforms. This just
makes it clear that blocks of code or components that deliver missing
parts of an open standard stack or enable support for free formats are
oky. i.e A svg viewer in flash for older browsers that don't natively
support svg, a flash or ActiveX uploading component for browsers that
don't support html5 xhr uploads... Or once WebM is supported in the
flash runtime, using the flash proprietary subcomponent so that IE and
Safari users can view WebM while other html5 free format browsers (
chrome, firefox, opera ) view it with their native html5 decoders.
This would rule out the start of the thread closed source flash applet
panaram thing for two reasons 1) Because the source code to the applet
is closed, and 2) because we did not first have feature parity with an
open standards solution. This would be solved by A) writing an open
source flash applet for panarama images and 2) Writing a javascript /
webGl based panarama system that worked with the WebGl open standard in
a shipping free software browser ie firefox 4 or google chrome.
peace,
--michael
On 09/17/2010 04:13 PM, Michael Snow wrote:
I believe part of the issue is the difficulty of
conceding the matter
when it comes to workarounds (designed to bring people in a broken,
non-free environment to parity of experience with everyone else) and
still holding the line when it comes to enhancements that should have a
freely available underpinning. Which, if I understood correctly, was the
nature of the original suggestion. That kind of situation could lead us
to dependency on proprietary software, or force people with a hardcore
approach to freedom in their own environment to accept that they can
only get an inferior experience. And what's a workaround or an
enhancement may fluctuate in different contexts.
Anyway, if you want to know better what the board's position was or is,
understand the rationale for it, evaluate if a particular deployment
would raise concerns, or make the case for a change, I would suggest
starting with Kat Walsh. She has as good a grasp of the issues here as
anyone on the board, and her views would carry weight with other board
members.
--Michael Snow
Michael Dale wrote:
If that is in fact the present board stance it
should A) It should be
stated somewhere and B) be lobbied to be changed.
The only statements I have seen from the board had to do with free
formats. What do free formats have to do with targeting propitiatory
applet interpreters?
If Danese is interpreting something specific she should point us to that.
There are complete free tool-chains for flash applet code, compilation,
and runtime.
It would be complicated to construct such a rule without going against a
lot of what we are already doing. Ie We have lots of custom IE markup
and javascript workarounds. Hence we are targeting a proprietary
interpreter. The Cortado video applet for example also has custom code
to support MS Java VM etc.
If free software flash applet code gets read by a propitiatory applet
and it helps give a large set of users an experience that is nearly
identical to the free software solution, then I really see no problem
with that, and its not very different from what we area already doing.
A flash applet as transitional technology to support older browsers
should be understood as very similar to 'making javascript work in IE'.
If instead you relied on some proprietary sub-system of IE to achive the
same thing with custom js/ actionsScript its really not that different.
Of course feature and experience parity with free software solutions is
a good rule to have. Which maybe what is being referenced here?
And using free formats for audio/ video is of course very important and
something I have supported for years.
peace,
--michael
On 09/17/2010 02:42 PM, Neil Kandalgaonkar wrote:
I agree with you completely, that Flash is useful
as a transitional
technology. But I got a very firm no from Danese who is interpreting
what the Board has said in the past.
There was a thread on Wikitech-L about this (you were probably
distracted at the time due to family stuff).
http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg08550.html
On 9/17/10 2:25 PM, Michael Dale wrote:
> On 09/17/2010 12:24 PM, Neil Kandalgaonkar wrote:
>
>
>> Discussions about using closed source tools are not taboo. Not at
>> all, I
>> think we should continue to review decisions about tools. I myself have
>> raised questions about (for instance) our decision to never use Flash,
>> even if we use a 100% free toolchain.
>>
>>
>>
>>
> I don't think we were ever against flash player as part of a tool set to
> widely support free formats.
>
> Flash is widely deployed consistent applet environment, there is no
> reason to avoid supporting it if it helps distribute ~free~ content. For
> example we have had brief talks of adding flash svg viewer so that IE
> users could better interact with SVG files. And you can be sure that
> once adobe ships native support for WebM it will provide much better
> experience for IE visitors to view free format videos than the
> fragmented java VM ecosystem that cortado has to run in.
>
> The foundation has only had a position of support for free formats, it
> has to my knowledge never stated any position against proprietary
> clients viewing free content or open source applets in proprietary
> platforms. Most of our visitors use IE after all.
>
> --michael
>
> _______________________________________________
> Commons-l mailing list
> Commons-l(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/commons-l
>
>
_______________________________________________
Commons-l mailing list
Commons-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/commons-l
_______________________________________________
Commons-l mailing list
Commons-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/commons-l