On 27/02/2015 9:14, Anne van Kesteren wrote: On Thu, Feb 26, 2015 at 8:31 PM, Antonio Manuel Amaya Calvo <[email protected]><mailto:[email protected]> wrote:
BTW, exposing new APIs is not hard... agreeing to make them available to everyone on the web is a loooong process though ;). This way we don't really add anything new to the web, we just use what's currently available on a device efficient way, and can be pegged as implementation details. If only it were that easy :-) We can't add some magic unexplained <iframe> variant to the web, claim victory, and hope nobody notices. Well, we only need to add a magic explained (I did explain it after all, I think :P) <iframe> variant to the web because FirefoxOS already has some other magic more or less explained <iframes> (mozapp, and mozbrowser). The only reason a new iframe is needed is because on FirefoxOS (and I believe that's specific for FirefoxOS) we have process separation for apps, and: * The parent process enforces a strict permission list on the childs so when it forks a new child it knows what permission it has, and if a child requests a permission it doesn't have at fork time, it's killed. Because of this we do need the iframe hosting the service app to be remote, because otherwise it cannot have more permissions than the hosting iframe. * Since our devices tend to be very limited on memory, and we're forking new processes per app, it's desirable that the new remote iframe reuses any process already alive for that app/service, to save on memory. That two things don't change the semantic at all, and as I said they're implementation details, for FirefoxOS only. If FirefoxOS process model were different (and/or if our devices had metric tons of memory ;)) then we wouldn't even need to hint the browser that "this iframe is special, please see if you can treat it with care". For the rest, the proposal is not different from having an external https://webreakcorsforyou.com server that allows itself to be embedded on an iframe and responds to postMessages with an URL with the content of that URL (which the server, not the client, downloads). And that's something we can *already* do on the web, without needing new browser APIs. Best, Antonio See also the emails here that discuss a very similar idea: https://lists.w3.org/Archives/Public/public-webapps/2014OctDec/thread.html#msg352 https://lists.w3.org/Archives/Public/public-webapps/2014OctDec/thread.html#msg379 I think we'll have to embrace that there are no shortcuts and start figuring out what needs to become a service and what needs to become something the browser needs to expose as an API. ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
