Dear commoners
We see an increasing number of spherical panoramics on commons [1], which makes me happy. Those pictures are best viewed in a panoramic viewer.
Unfortunately when I compare our panoramic viewer [2] with the one i.e. on 360cities [3] - they use krpano [4] - I conclude: -Our Java system requires a faster computer than the Flash player resulting in slow loading or errors. -Our system is not able to progressively display the current view. That means it takes a longer time until you can start browsing. -The User Interface looks rather spartanic compared to the smooth one of krpano.
So the question is why not switch to a better system if it's available? After a quick look I got the impression that krpano is currently state of the art but you may know another program.
I'm interested to hear your opinions.
Regards
Robin
[1] https://secure.wikimedia.org/wikipedia/commons/wiki/Category:Spherical_panor... [2] http://toolserver.org/%7Edschwen/pano/index.php?f=Spitzkoppe_360_Panorama.jp... [3] http://www.360cities.net/ [4] http://krpano.com/
Hey Robin, so I guess I'll answer here instead of on my userpage [1]
After a quick look I got the impression that krpano is currently state of the art but you may know another program.
krpano is not an option, it is non-free. A alternative would be panosalado2, but last time I checked it had numerous problems, such as * lack of documentation * the need to re-project images into a cube panorama format before the multiresolution modus works (needed to get an improvement for large images over the current viewer) * lack of cylindrical projection support * lack of cut-off spherical pano support
The last two points mean that approximately 99.9999% of the panos on commons will NOT work with Panosalado.
Believe me I looked hard for an alternative, and all I got was hours of grief! Daniel
[1] http://commons.wikimedia.org/wiki/User_talk:Dschwen#Panoramic_viewer
With Firefox 4 landing soon and webGL support increasing ( chrome, safari .. maybe even IE someday ) ... it would probably be best to use something like: http://webuser.hs-furtwangen.de/~dersch/PTViewerNG/PTViewerNG.html
It looks like that was hacked up fairly quickly ... but someone would have to improve its support across modern browsers and possibly have a fall-back to flash mechanisms for viewers.
I will definitely put looking at that in my long term todo list. I think it would make for an interesting plugin for the sequencer efforts as well, ie including pans on panoramas as section of a documentary.
--michael
On 09/15/2010 12:49 PM, Daniel Schwen wrote:
Hey Robin, so I guess I'll answer here instead of on my userpage [1]
After a quick look I got the impression that krpano is currently state of the art but you may know another program.
krpano is not an option, it is non-free. A alternative would be panosalado2, but last time I checked it had numerous problems, such as
- lack of documentation
- the need to re-project images into a cube panorama format before the
multiresolution modus works (needed to get an improvement for large images over the current viewer)
- lack of cylindrical projection support
- lack of cut-off spherical pano support
The last two points mean that approximately 99.9999% of the panos on commons will NOT work with Panosalado.
Believe me I looked hard for an alternative, and all I got was hours of grief! Daniel
[1] http://commons.wikimedia.org/wiki/User_talk:Dschwen#Panoramic_viewer
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
On 15.09.2010 22:49, Daniel Schwen wrote:
krpano is not an option, it is non-free. A alternative would be panosalado2, but last time I checked it had numerous problems, such as
Why being so dogmatic? I agree that free software is a must for core components of our project for strategic reasons. However for secondary components such as an image viewer I see no such strategic reasons.
And if somebody programmed a nice piece of code that you can't easily write yourself why not pay for it? At least if the price of 90USD is marginal for an organization like Wikimedia.
Regards
Robin
On 16 September 2010 11:19, Robin Schwab contact@robinschwab.ch wrote:
Why being so dogmatic? I agree that free software is a must for core components of our project for strategic reasons. However for secondary components such as an image viewer I see no such strategic reasons.
Because content that requires a proprietary viewer is considered problematic. This is why Commons requires free formats.
- d.
On 16.09.2010 13:46, David Gerard wrote:
On 16 September 2010 11:19, Robin Schwabcontact@robinschwab.ch wrote:
Why being so dogmatic? I agree that free software is a must for core components of our project for strategic reasons. However for secondary components such as an image viewer I see no such strategic reasons.
Because content that requires a proprietary viewer is considered problematic. This is why Commons requires free formats.
I'm not talking about allowing content in a proprietary file format. All those panoramics are jpg files. I only propose to put a proprietary software on our servers giving the user an alternative way to see those jpg files.
Regards
Robin
Robin Schwab wrote:
On 16.09.2010 13:46, David Gerard wrote:
On 16 September 2010 11:19, Robin Schwabcontact@robinschwab.ch wrote:
Why being so dogmatic? I agree that free software is a must for core components of our project for strategic reasons. However for secondary components such as an image viewer I see no such strategic reasons.
Because content that requires a proprietary viewer is considered problematic. This is why Commons requires free formats.
I'm not talking about allowing content in a proprietary file format. All those panoramics are jpg files. I only propose to put a proprietary software on our servers giving the user an alternative way to see those jpg files.
Whether it's the file format or the viewer, I don't see that much difference and I think the question has pretty much been asked and answered already. Part of the issue is that we're committed not just to freedom of access, but also freedom of reproduction, so that mirrors or downstream users should be able to freely recreate the experience if they wish.
If the Wikimedia Foundation tried to absorb the costs of proprietary software as suggested, there are a couple problems. The first problem is that the foundation can only absorb some, not all, of the social impacts of such a choice, no matter how much it tries to pick up the full logistical and financial costs. The second problem is what else the foundation would start to absorb, in the sense of cultural connections and obligations, as a result of making such a choice.
For reasons such as this, content solutions on our side need to remain free in the fullest sense of the word. People are welcome to try whatever they like downstream or on the client side, and that's the place to work on non-free "solutions" to such problems. After all, there's no problem if someone wants to read Wikipedia using Internet Explorer, either.
--Michael Snow
On 16.09.2010 18:35, Michael Snow wrote:
Whether it's the file format or the viewer, I don't see that much difference and I think the question has pretty much been asked and answered already. Part of the issue is that we're committed not just to freedom of access, but also freedom of reproduction, so that mirrors or downstream users should be able to freely recreate the experience if they wish.
I have some understanding for that argument. However mirrors etc. would still have the alternative of using the free but bad quality viewers if they don't want to spend the 90$.
If the Wikimedia Foundation tried to absorb the costs of proprietary software as suggested, there are a couple problems. The first problem is that the foundation can only absorb some, not all, of the social impacts of such a choice, no matter how much it tries to pick up the full logistical and financial costs. The second problem is what else the foundation would start to absorb, in the sense of cultural connections and obligations, as a result of making such a choice.
Those are very weak arguments: social impact... cultural connections... We live in a world of competition between open source and proprietary software. This competition has blossomed into products like Firefox or Windows 7. When we /a priori/ exclude one or the other we will miss the chance of using the really best software. I'm disappointed to see Wikimedia being trapped in it's own philosophy.
Given this situation the only alternative we have is to actively let somebody program the requested feature or to wait until somebody does it spontaneously. Both ways it may take years to have a satisfactory result.
Regards
Robin Schwab
On 16 September 2010 17:49, Robin Schwab contact@robinschwab.ch wrote:
Those are very weak arguments: social impact... cultural connections... We live in a world of competition between open source and proprietary software. This competition has blossomed into products like Firefox or Windows 7. When we /a priori/ exclude one or the other we will miss the chance of using the really best software. I'm disappointed to see Wikimedia being trapped in it's own philosophy. Given this situation the only alternative we have is to actively let somebody program the requested feature or to wait until somebody does it spontaneously. Both ways it may take years to have a satisfactory result.
Wikimedia tends to choose "unambiguously free" over "expedient" every time, so it's not clear why an exception would be made in this case.
There are exceptions. I believe we used Java before it was entirely free software, and our image server was Solaris 10 for a while though I believe that's changing. If you really think you can put a case as to why this should go through, you could argue it on wikitech-l. I don't like your chances, but it's possible.
- d.
On 9/16/10 9:49 AM, Robin Schwab wrote:
Those are very weak arguments: social impact... cultural connections...
Maybe. But an all-free-software policy can be defended, even on the grounds of pure expediency.
I'm a developer and I've worked in situations that were a mix of proprietary and free software. I much prefer it when it's all-free, or at least as much as possible.
I have frequently had to tell people "sorry, that's impossible" when working with a proprietary tool. When we are working with free tools, the only limit is how much attention or skill we can bring to the problem. If necessary, we can write the software ourselves.
Also, if we know that all of our software and data can be replicated without limit on any server, backups, archives, even a developer's machine, that's a huge win for many reasons. It's easier for ops, easier to archive, easier for remote developers, easier for researchers. The WMF doesn't have to have anybody doing useless tasks like tracking software license compliance.
When we /a priori/ exclude one or the other we will miss the chance of using the really best software.
Yup. We are not using the best software today. We are trading that for the assurance that we can do *whatever* we want, today, or in the future.
Given this situation the only alternative we have is to actively let somebody program the requested feature or to wait until somebody does it spontaneously. Both ways it may take years to have a satisfactory result.
I agree that this sucks, and there ought to be some better way to fund free software development. Right now we rely mostly on developer caprice, or relatively unusual situations where a company finds it in their interest to give away their code.
However, that is the angle we should be working on - how can we fund the software we want to have - rather than looking for some compromise with proprietary software, which we know will come back to haunt us.
On 9/16/10 11:02 AM, Neil Kandalgaonkar wrote:
Also, if we know that all of our software and data can be replicated without limit
Oh and I forgot a very large benefit: this greatly reduces our exposure to any lawsuits based on software or patents.
Anyway, I know you are really just advocating for a temporary, small, concession to using a better pano viewer, and you aren't looking for philosophical arguments.
I wish I had a better answer for you.
On 16 September 2010 19:02, Neil Kandalgaonkar neilk@wikimedia.org wrote:
On 9/16/10 9:49 AM, Robin Schwab wrote:
Those are very weak arguments: social impact... cultural connections...
Maybe. But an all-free-software policy can be defended, even on the grounds of pure expediency. I'm a developer and I've worked in situations that were a mix of proprietary and free software. I much prefer it when it's all-free, or ateast as much as possible. I have frequently had to tell people "sorry, that's impossible" when working with a proprietary tool. When we are working with free tools, the only limit is how much attention or skill we can bring to the problem. If necessary, we can write the software ourselves.
+1
I'm a sysadmin. Proprietary tools are the bane of my existence and the object of considerable fear and loathing. They are to be avoided as absolutely far as possible. Any exceptions had better (a) have the best excuse ever in history (b) be replaceable with an open source equivalent as absolutely soon as is feasible.
Your mileage may vary, but I suspect it won't vary much.
- d.
On 17.09.2010 00:13, David Gerard wrote:
On 16 September 2010 19:02, Neil Kandalgaonkarneilk@wikimedia.org wrote:
I have frequently had to tell people "sorry, that's impossible" when working with a proprietary tool. When we are working with free tools,
I'm a sysadmin. Proprietary tools are the bane of my existence and the object of considerable fear and loathing. They are to be avoided as
That is what I found a bit sad in this discussion: It's based on "fear and loathing" instead of user-centered delivery of the best service. In this case we told the people "sorry, that's impossible" because any proprietary tool is /tabu/.
Anyway, thanks for sharing your thougts.
Robin
On 16 September 2010 22:57, Robin Schwab contact@robinschwab.ch wrote:
That is what I found a bit sad in this discussion: It's based on "fear and loathing" instead of user-centered delivery of the best service. In this case we told the people "sorry, that's impossible" because any proprietary tool is /tabu/.
Yes, it must just be nine years of collective stupidity.
- d.
On Fri, Sep 17, 2010 at 7:57 AM, Robin Schwab contact@robinschwab.ch wrote:
On 17.09.2010 00:13, David Gerard wrote:
On 16 September 2010 19:02, Neil Kandalgaonkarneilk@wikimedia.org wrote:
I have frequently had to tell people "sorry, that's impossible" when working with a proprietary tool. When we are working with free tools,
I'm a sysadmin. Proprietary tools are the bane of my existence and the object of considerable fear and loathing. They are to be avoided as
That is what I found a bit sad in this discussion: It's based on "fear and loathing" instead of user-centered delivery of the best service. In this case we told the people "sorry, that's impossible" because any proprietary tool is /tabu/.
The fear and loathing comes from experience.
Lots of effort is 'wasted' on implementing proprietary solutions.
They may give short term advantages in user-experience, however that user-experience is then tied to the release schedule and whims of the vendor.
-- John Vandenberg
On 16 September 2010 23:55, John Vandenberg jayvdb@gmail.com wrote:
The fear and loathing comes from experience. Lots of effort is 'wasted' on implementing proprietary solutions. They may give short term advantages in user-experience, however that user-experience is then tied to the release schedule and whims of the vendor.
And most importantly: when it breaks, you're fucked.
The same can happen with open source, but you're much less likely to have a vendor do it to you as part of their plan to brutalise your last pennies out of you.
(so, anyone else work with Solaris and Java and watch the Oracle takeover in sheer horror?)
- d.
On 9/16/10 2:57 PM, Robin Schwab wrote:
That is what I found a bit sad in this discussion: It's based on "fear and loathing" instead of user-centered delivery of the best service.
I'm not sure I understand this complaint. Are you suggesting that we should just accept the pain (as developers) in order to provide the best experience later?
By fear and loathing I don't think we meant something that would be confined to just developers and administrators. Trust me, our pain would be your pain too.
In this case we told the people "sorry, that's impossible" because any proprietary tool is /tabu/.
I think you are trying to imply we are limited thinkers here. Perhaps, but we are not shutting you down just for violating a cultural norm against the sacred god Oh-Ess-Ess.
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.
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
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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Hoi, Would it be an option to use the GNASH server implementation at the WMF end. As long as a particular Flash file works, it can be served with a completely free software stack. It is then for the end-user to choose to use either the Gnash or the Flash client software..
There are advantages to Gnash, it has among other things a lower memory foot print.. Thanks, GerardM
On 17 September 2010 23:42, Neil Kandalgaonkar neilk@wikimedia.org 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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
-- Neil Kandalgaonkar |) neilk@wikimedia.org
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l