On 2014-04-15, 7:14 PM, Vladimir Vukicevic wrote:
On Tuesday, April 15, 2014 5:57:13 PM UTC-4, Robert O'Callahan wrote:
On Wed, Apr 16, 2014 at 3:14 AM, Benoit Jacob <jacob.benoi...@gmail.com>wrote:
I'm asking because the Web has so far mostly been a common denominator,
conservative platform. For example, WebGL stays at a distance behind the
forefront of OpenGL innovation. I thought of that as being intentional.
That is not intentional. There are historical and pragmatic reasons why the
Web operates well in "fast follow" mode, but there's no reason why we can't
lead as well. If the Web is going to be a strong platform it can't always
be the last to get shiny things. And if Firefox is going to be strong we
need to lead on some shiny things.
So we need to solve Vlad's problem.
It's very much a question of pragmatism, and where we draw the line. There are
many options that we can do that avoid having to consider almost-open or
almost-free licenses, or difficulties such as not being able to accept
contributions for this one chunk of code. But they all result in the end
result being weaker; developers or worse, users have to go through extra steps
and barriers to access the functionality. I think that putting up those
barriers dogmatically doesn't really serve our goals well; instead, we need to
find a way to be fast and scrappy while still staying within the spirit of our
mission.
Note that for purposes of this discussion, "VR support" is minimal.. some
properties to read to get some info about the output device (resolution, eye distance,
distortion characteristics, etc) and some more to get the orientation of the device.
This is not a highly involved API nor is it specific to Oculus, but more as a first-put
based on hardware that's easily available.
I also briefly suggested an entirely separate non-free repository -- you can
clone non-free into the top level mozilla-central directory, or create it in
other ways, and configure can figure things out based on what's present or not.
That's an option, and it might be a way to avoid some of these issues.
Hmm, that might actually work very easily, I _think_ closing that repo
into extensions/ under a name such as oculus and then building with
--enable-extension=oculus would just make the build system traverse that
directory, right? Then we can add our Gecko code on top of it based on
build system conditions such as |if 'oculus' in
CONFIG['MOZ_EXTENSIONS']| in moz.build files, so if you have the oculus
repo cloned under extensions/ and have the right mozconfig entry,
everything will work out of the box.
Does that seem useful?
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
