> Well, the it's going to be very amusing then when we start telling people to use service workers, > which rely both on CORS and TLS ^_^. The same with Geolocation, which we hope to move to > requiring TLS to access it. I'm sure there was a time before TLS was not well supported on servers > when someone exclaimed "A [insert thing here] that only works on the 2 servers in the world that > supports [TLS] is not a sensible suggestion"! Hell, someone probably shouted the same > thing about HTTP back in 1991, lol:)
> All browsers support CORS now (http://caniuse.com/#search=cors). To not enable > it for an app is irresponsible. To not require TLS for service workers would put users > privacy at risk. So are we also going to chicken-out and do a "System Service Workers" > because not enough developers have TLS? The problem is not browser support for CORS, which has for quite a long time had pretty good support. The issue is that there are applications that in order to function require access to arbitrary remote services which we do no control. This is entirely different from the decision (which I disagree with) for TLS to be required for ServiceWorkers (or Geolocation / GUM) where the developer in the typical case has control over the stack and can choose to implement https however the developer cannot control wether arbitrary remote servers implement CORS. I will let others speak for particular use cases, however as I mentioned earlier there is a simple explanatory use case, a read it later / RSS application in which a user specifies a list of remote origins they would like data to be fetched from and stored offline to be read at their convenience. If the developer did not have the ability to use systemXHR, then this app would be limited to reading a very small number of sites to the point where it would be a useless application, asking every site administrator on the internet to enable CORS is obviously unfeasible and there is not a particular incentive for site administrators that arent actually using CORS themselves to bother implementing it. So by saying access to a remote server is a solved problem because CORS is saying that a read it later app / RSS reader are not and never will be part of the web, as well as a long list of other use cases I havent mentioned Its worth mentioning in the case of ServiceWorkers an entirely new api for network access that supported workaround for cors (no-cors requests with opaque responses) had to be implemented On 17 February 2015 at 13:01, Benjamin Francis <[email protected]> wrote: > On 17 February 2015 at 02:27, Marcos Caceres <[email protected]> wrote: > >> >> These are great questions. I think we should find some apps that actually >> do this (or want to do this), and talk more seriously about how to enable >> that. >> > > Gaia apps are apps that do this, please don't disregard the experience > that has come from trying to build Gaia apps as web apps (they really did > start out that way, using appcache and served over HTTP) over a number of > years. Gaia is a great place to look for gaps in the web platform, because > every new API that Gaia uses was created to fulfil a requirement that the > web platform could not meet. We might have had to take some shortcuts along > the way (like packaged apps) to get a product out of the door, and we might > not yet have found the optimal solution to every use case, but the goal [1] > has always been to build Gaia using the web. > > >> This is the confusion: the camera app is a system service - it's not a >> web app. Of course camera input is not going to work there. The camera >> service is *supposed enable <input type="file" >> accept="image/*;capture=camera">*, not the other way around. >> > > Unfortunately that isn't good enough. We want to be able to build > Instragram using the web. That won't work if the system provides the only > camera UI as browser chrome, which Instagram accesses by pressing a camera > button. Instagram wants to *be* the camera UI. If the developers of > Instagram can't build the experience they want to build using the web, then > they will just use other proprietary platforms instead. > > >> >> By design, you can't build system-level services an apps using web >> technology. That's what c++, Rust, or certified-level APIs are for. >> > > Broadly speaking the goal of the B2G project is to fix that problem, by > redefining what is "system-level" and what can be built using the web. I > agree there should be a clear boundary between what is the web and what > isn't the web, but perhaps you don't quite appreciate the extent of what > we're asking the web to do :) > > Ben > > 1. https://wiki.mozilla.org/Booting_to_the_Web > > > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g > >
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
