> On Jul 25, 1:23 pm, Mike Shaver<mike.sha...@gmail.com> wrote: >> On Mon, Jul 25, 2011 at 1:19 PM, Rob Campbell<rcampb...@mozilla.com> wrote: >>> Why Android and not a PC to start with? Would it be easier? Fewer moving parts, fewer device unknowns? Is a PC-level device on the table as well?
>> We might prototype some stuff on a PC, but the project is really about >> the device space. We had to pick somewhere, and this seems like where >> the energy is best spent.
>> Desktop devices tend to be harder to get good open drivers for without >> pulling in things like X, which we don't want to do.
> I don't know the current state of Android/x86 but wouldn't that also > be a good platform to develop on? It could be an easy way to bootstrap > this. Same Android layer, same Gecko code, lots of overlap with Fennec/ > Linux. It would mean that we could hack on BootToGecko on a much > easier to handle environment that runs in VMWare of VirtualBox.
Sure, that's an option. Note that the android SDK includes an emulator based on qemu, so running B2G/ARM builds on your desktop isn't necessarily a problem (because of the emulator).
On Mon, Jul 25, 2011 at 3:53 PM, Ian McKellar <ian.mckel...@rd.io> wrote:
> On Monday, July 25, 2011 at 10:27 AM, Mike Shaver wrote:
>> Our experiences with performance and hardware acceleration on X >> haven't been great
> I think that's getting better and better. Nvidia seems (based on my googling) to have drivers available for X for their Tegra chipsets. Tegras are powering most of the nicer Android phones coming out today.
Tegra is an obvious choice for a start (But - nvidia often make the closed, proprietary drivers, i wonder if they missed their usual politics on Tegra..) - uprising mega-platform, performance is good etc.
But:
>We'll evaluate them, but for right now we want to take advantage of >the work we've already done (and are doing) on Android
i understand that tweaking the gecko once for both Android and Android is cool, but isn't there already enough of Android and it's SDK? aren't there are pretty mature https://secure.wikimedia.org/wikipedia/en/wiki/SHR_(operating_system) and other variants, many other, more natural - GNU/Linux variants.
Could you, please, tell - when do you plan to evaluate these non-Android variants?
So we could decide if the petition to Mozilla about non-Android OS is appropriate now.
On Mon, Jul 25, 2011 at 5:12 PM, ya knygar <kny...@gmail.com> wrote: > i understand that tweaking the gecko once for both Android and Android is cool, > but isn't there already enough of Android and it's SDK?
Apps won't use the Android SDK, they'll use current-and-future Web APIs.
> Could you, please, tell - when do you plan to evaluate these > non-Android variants?
I don't know of any plans to evaluate SHR; I don't have any devices it runs on, personally, and none of the ones listed in Wikipedia are very interesting to target IMO. We have a lot of work to do even starting from a working operating system. Adding OS-bringup to our plate isn't really attractive to me at this time.
If you or someone else would like to evaluate SHR, on the other hand, that would be welcome information. Just telling us that we shouldn't look at Android is unlikely to be very effective, since that's where we feel our work is best directed right now. Facts coming out of evaluation of Android and other proposed platforms would be much more influential, because they can actually help inform decisions.
I really don't think that using the App Launcher draft as any manner or form of starting point is a good idea. The DAP group has it in its CVS because it is inherited from the APIs that were submitted to it in the beginning, but it's since been abandoned and IMHO for very good reason. I don't think that a cleaned up version will get you anywhere interesting, you need a completely different design.
The problem with the App Launcher API is that there is pretty much no way of making it safe for Web use without making it useless. At the more powerful end of this spectrum you can enumerate installed executables (how that works is in itself an issue, not to mention how you filter it for privacy) and can then run them. I don't think that there is any kind of user interface that will make that functionality safe to run from the Web. At the other end of the spectrum you can have methods like "launch the music player with this". These are typically best served by media types and URI schemes.
Of course you could do something like that if the goal were not to make the APIs in B2G not be Web-safe. But I don't see the value in this, and from reading between the lines I think that the idea is that all of the B2G stack be built with Web APIs. Any monkey with enough time can wrap every lib on the system with js-ctypes but I don't see much value in that. What's hard (and interesting) is to make it work for the Web. That's why DAP dropped App Launcher in favour of an Intents/Introducer approach.
That's not to say that I don't see value in your proposal of having a runtime that can be used on top of an OS rather than requiring a complete replacement. I could well be missing something but I see no reason why the project couldn't have a minimal OS that's just enough to launch the runtime, which in turn could also run elsewhere. But either way there's a bit of code to write before such refinements :)
> On Jul 25, 2011, at 19:47 , Fabrice Desré wrote: >> - An API to list/launch native android apps (based a cleaned up version >> of http://dev.w3.org/2009/dap/app-launcher/)
If there is a way to launch native android apps from such a system, it would be the same kind of temporary wart that plugins like Flash and Silverlight are for the desktop web platform. If we can't deliver the necessary WebAPIs quickly enough and need Android apps to fill in web platform gaps temporarily, an Android app stop-gap measure might be an acceptable temporary kludge.
In a final system, I don't see much value for this proposal though. The web is in so many ways superior to the locked-in proprietary stores/APIs that it will subsume them pretty quickly as long we make sure the right APIs are in place. This is happening on the desktop today. Your proposal is akin to suggesting that we should urgently add a way to launch Java/native code desktop applications from the desktop browser. It might serve some specific corner cases today, but I doubt it will be relevant in the future.
On Mon, Jul 25, 2011 at 5:36 PM, Robin Berjon <ro...@berjon.com> wrote: > Hi Fabrice,
> On Jul 25, 2011, at 19:47 , Fabrice Desré wrote: >> - An API to list/launch native android apps (based a cleaned up version >> of http://dev.w3.org/2009/dap/app-launcher/)
Android apps won't likely run on this system once we're done stripping it down, any more than Linux applications run on Android, so the launcher isn't likely to be useful even independent of Robin's well-articulated concerns.
> That's not to say that I don't see value in your proposal of having a runtime that can be used on top of an OS rather than requiring a complete replacement. I could well be missing something but I see no reason why the project couldn't have a minimal OS that's just enough to launch the runtime, which in turn could also run elsewhere.
Whatever we run on top of, we have to bind all these various capabilities, and many operating systems don't currently expose enough for us to, f.e., write a dialer app. We'll want to validate against multiple operating systems in time, but we have to start somewhere, ideally where we can hack our way around current limitations in the lower-level stack.
> But either way there's a bit of code to write before such refinements :)
On Jul 25, 11:47 am, Chris Jones <cjo...@mozilla.com> wrote:
> On 07/25/2011 02:16 PM, Marco Zehe wrote: > > This has some interesting implications for accessibility which I'll be > > blogging about in the near future. Just an initial thought:
> > We would need the capability to install speech synths so blind users > > could use a (yet to be written) extension/possibly part of the browser > > that provides them speech feedback in all environments. For that, > > whichever we include from Android, we'd need to make sure that the > > speech services framework is part of that.
> Speech synthesis is a capability we want to have, but it's not something > we necessarily need to import an android framework for. Speech > synthesis can be implemented by web pages, today, using JavaScript and > audio APIs.
I definitely agree that sort of thing can be done on web pages. We can also compile existing C/C++ codecs into JS for this (perhaps even the relevant Android framework itself).
In general I think that making it easier for people to compile stuff into JS, as opposed to adding new native code into the browser, is the preferable approach, at least for things like this (codecs/logic/non- hardware accessing stuff).
On Jul 25, 3:39 pm, Mike Shaver <mike.sha...@gmail.com> wrote:
> On Mon, Jul 25, 2011 at 3:30 PM, Stefan Arentz <stefan.are...@gmail.com> wrote:
> > I don't know the current state of Android/x86 but wouldn't that also > > be a good platform to develop on? It could be an easy way to bootstrap > > this. Same Android layer, same Gecko code, lots of overlap with Fennec/ > > Linux. It would mean that we could hack on BootToGecko on a much > > easier to handle environment that runs in VMWare of VirtualBox.
> Depending on the state of Android/x86, that sounds very promising. > Does that work for Fennec stuff now?
> Mike
I think this is a great idea for the web, but security has to be one of the center pieces around this OS.
In my opinion, Android is suffering from attacks because some of their source code is very sensitive to the platform and is constantly being the victim of malware attacks.
As a huge Android supporter i dont see why you find the need to do this.
Android is already a great mobile O.S. that is open source.
It may run native apps but i see no problem with that. Plus, it has a great browser that is always getting better with each release so it supports the HTML5 web apps that mozilla (and also google) likes.
If Mozilla wants to support open source and the web in mobile devices you should better work as much as possible on the Android version of Firefox instead of trying to create a whole new O.S.
There is no need for another O.S. if you can build a great Firefox app for an existing open source O.S. that is already out on the market and growing faster than the closed systems like apple's and microsoft's.
You may think that i may be saying this because i love Android but there is much logic and reason in my words.
On Mon, Jul 25, 2011 at 5:28 PM, Nick Dafo <nickdafomob...@gmail.com> wrote: > It may run native apps but i see no problem with that. Plus, it has a > great browser that is always getting better with each release so it > supports the HTML5 web apps that mozilla (and also google) likes.
It doesn't have a great browser at all; it is at best mediocre. No web-worker support (was there in 2.1, disappeared in 2.2+), poor support for CSS transforms. No SVG support until honeycomb came out. No WebGL. No inline html5 video. Poor performance overall (network, graphics, and touch) and it's full of quirks across manufacturers (ex: my phone doesn't show scrollbars). Also, I can't upgrade it. It may get better in each release but I am at the mercy of the carriers/oems for upgrading. I am essentially locked into one version of the browser, maybe two if I'm lucky (though little changed in Gingerbread).
> As a huge Android supporter i dont see why you find the need to do > this.
> Android is already a great mobile O.S. that is open source.
Android is not open source in the sense of "open technology". Android APIs are proprietary Google sauce, not broadly accepted and adopted open web standards. At some point Android used to be at least "available source" where Google would publish secretly/internally developed source code/technology after the fact as products ship, but even those times seem to be over now. I would love to boot my custom Android build on my Galaxy Tab 10", but no luck, Google refuses to release the source.
We want to do Boot to Gecko the way we think open source should be done. In the open, from day 1, for everyone to see and participate.
On Tue, Jul 26, 2011 at 01:23, Mike Shaver <mike.sha...@gmail.com> wrote: > On Mon, Jul 25, 2011 at 1:19 PM, Rob Campbell <rcampb...@mozilla.com> wrote: >> Why Android and not a PC to start with? Would it be easier? Fewer moving parts, fewer device unknowns? Is a PC-level device on the table as well?
> Desktop devices tend to be harder to get good open drivers for without > pulling in things like X, which we don't want to do.
Since this is about the future, did you consider Wayland? Afaik it has been designed for use on embedded devices as well.
> Mozilla believes that the web can displace proprietary, single-vendor stacks for application development. To make open web technologies a better basis for future applications on mobile and desktop alike, we need to keep pushing the envelope of the web to include --- and in places exceed --- the capabilities of the competing stacks in question.
> We also need a hill to take, in order to scope and focus our efforts. Recently we saw the pdf.js [http://github.com/andreasgal/pdf.js/] project expose small gaps that needed filling in order for "HTML5" to be a superset of PDF. We want to take a bigger step now, and find the gaps that keep web developers from being able to build apps that are --- in every way --- the equals of native apps built for the iPhone, Android, and WP7.
> To that end, we propose a project were calling "Boot to Gecko" [http://wiki.mozilla.org/B2G] (B2G) to pursue the goal of building a complete, standalone operating system for the open web. Its going to require work in a number of areas.
> * New web APIs: build prototype APIs for exposing device and OS capabilities to content (Telephony, SMS, Camera, USB, Bluetooth, NFC, etc.) > * Privilege model: making sure that these new capabilities are safely exposed to pages and applications > * Booting: prototype a low-level substrate for an Android-compatible device; > * Applications: choose and port or build apps to prove out and prioritize the power of the system.
> We will do this work in the open, we will release the source [http://github.com/andreasgal/B2G] in real-time, we will take all successful additions to an appropriate standards group, and we will track changes that come out of that process. We aren't trying to have these native-grade apps just run on Firefox, we're trying to have them run on the web.
> This project is in its infancy; some pieces of it are only captured in our heads today, others arent fully explored. Were talking about it now because we want expertise from all over Mozilla -- and from people who arent yet part of Mozilla -- to inform and build the project were outlining here.
Very nice! Is it accurate to say that the point on "New web APIs" encompasses the ability to open UNIX sockets and similar interfaces?
Or to take it a step further, perhaps with this project, is it possible to build a new abstraction for networking? (thus avoiding the hairiness of sockets -> a JS-callable version of zeromq perhaps [http://www.zeromq.org/])
On Tue, Jul 26, 2011 at 11:55 AM, <bob_somer...@yahoo.com> wrote: > I hope this platform will run XUL apps. > That would be huge IMO. I would definitely > develop for it in that case.
XUL should not be considered. Chromeless works just fine.
> Speech synthesis is a capability we want to have, but it's not something > we necessarily need to import an android framework for. Speech synthesis > can be implemented by web pages, today, using JavaScript and audio APIs.
Yes, I was there when Dave Humphrey demoed this at Whistler 2010. The quality of the synth was...well...close to the 1980s. Seeing that it was written in pure JS, however, was fantastic! But I agree it's something worth looking at, and we need to be aware of multilingual support.
> We definitely want to hear what the a11y requirements are for this (and > in general!) so we can figure out what the best implementation might be.
We just recently made a decision on how to move forward with accessibility for Firefox Mobile on Android, and this work will definitely benefit the B2G project, and we can learn a lot this way.
Interesting. Might also give the opportunity for memory to be cooperatively managed by both browser and kernel, rather than the current unpalatable possibilities of either being summarily nuked or indiscriminately swapped.
> XUL should not be considered. Chromeless works just fine.
+1 for HTML/CSS/JS styling for everything in B2G.
> I don't know of any plans to evaluate SHR; I don't have any devices it > runs on, personally, and none of the ones listed in Wikipedia are very > interesting to target IMO. We have a lot of work to do even starting > from a working operating system. Adding OS-bringup to our plate isn't > really attractive to me at this time.
of-course but given the closed source of latest Android,
given that in opinion of many from FLOSS community - world would really benefit from GNU/Linux portable OS's (that, by the way, are developed and tested seriously by the community and would be used widely, sooner or later, SHR just another working example - could be installed on iPhones, and, most of the ARM's are just untested with it, not that there are many compatibility issues).
If Mozilla dev's would support the freedom OS's in one or other way - that would likely to rise the Question of vendor locked-mobiles and the possibility of mobiles computers to became a PC like machines in which user could easily install OS of the choice. Work on B2G would help it anyway, but supporting particularly a freedom OS's "back-end" could bring a much larger attention and what is more valuable - support of community, and, maybe, some amazing collaborative affords.
Supporting Android is rising up the questions that lead in a kind of different direction where - why do we need to re-flash OS if we could run the OS into OS like Chromeless OS's for example. Again - it's just my observation.
Porting to GNU/Linux would be done anyway, i think, but this is the point where, obviously, both Mozilla and GNU/FSF/etc. community would largely benefit from collaboration. And working with Google - given what i know about it's work with community, and helping the forks, in particular, is a controversial decision.
