On 26 Feb 2015, at 14:31, Vivien Nicolas <[email protected]<mailto:[email protected]>> wrote:
On Thu, Feb 26, 2015 at 12:02 PM, Antonio Manuel Amaya Calvo <[email protected]<mailto:[email protected]>> wrote: Hi there. In the frame of the recent arguments about the permission model and making the apps more webby and as a result more easily updatable (or the other way around), we've been playing with the idea (and trying to prototype) of having certified service-like apps that would encapsulate some permissions. That would be very cool imho. The rationale behind this is that there are some certified permissions (like settings) that are used by a bunch of apps that only need a small subset of the things the permission actually allow. So we could split the permission (as setting has actually done, in a way that requires Gecko to be aware of the specific settings that Gaia uses, see [1]!) or we could add a Gaia component that has access to the whole setting functionality and mediates on requests to fulfill them or not. Enter the services. Part of the design of the new Gaia architecture is to be able to prototype such a thing. Some apps can be built as 'Services' and multiple apps may access those Services to do some stuff. It is not yet implemented but this is on our 'things to explore' todo list. One way to implement the services would be (and that's what we're actually toying with) to use IAC or Datastores to communicate with them). But as we were reminded recently, there's little to no chance of those APIs being actually opened to the web. So... I thought another proposal, that seems webby enough. The idea is to define a new kind of frame, "mozservices". Those frames can be embedded on an app and when they are embedded: What I have been told is that there is a proposal from Google called 'Tubes' to allow cross-origin communication. I may have misunderstood and the name may not be the right one, but sicking knows. So maybe the cross-origin communication mechanism is still an option (but not IAC, nor DataStore). In Gaia the prototype would look a bit like: App: var c = new Client('settings', /* version */ '1.0'); c.get('some.setting').then(function(value) { // do something }); Remote Service: var s = new Server('settings', /* version */ '1.0' { get: function(setting) { // do something } }); Where Client and Server are client sides API based on Promises. The postMessage communication, is hidden into the lib in order to make it easier to use any new APIs that may comes one day. (fwiw this APIs is built primarily in order to have a clear communication API between views and workers). Why I would prefer that over embedding a frame ? - The iframe trick seems to just be a workaround around the lack of APIs to do cross-origin communication. The thing is that postMessage *is* an API designed specifically to do cross origin communication. Or that's how I understood it anyway :). In fact if I wanted to do cross origin communication on the web right now j would have to do it using postMessage. The trick here is that mostly for performance and security reasons we want those iframes to be reusable (have only one actual instance). - With the frame you need to know the url of the Service, which is something that may change, and it would be cool if third-party developers can create their own Services to replace ours in the future. That's right, but again, URLs are the standard way to identify objects/elements/resources on the web. So the difference is if the client app wants to use any settings service versus this specific service identified by this URL. - The service does not need to have a window object to return. It simply returns data.One of the cool thing we could build around Services too is the ability for the client to subscribe to some events. For example: var c = new Client('contacts', '1.1'); c.addEventListener('oncontactschanged', function(changes) { // do something }); While if the iframe does not have an opener (as you describe), it could only react to postMessage. So the iframe needs a way to know who has opened it to push those kind of notifications. Hmm that is a fair point. As I had seen this would work on a request/response way only, not on a publisher/subscriber way. In any case, what I had tried to do with this proposal was to *not* introduce any new API (which then would have to be designed and standardized and what not) but to see if we could do with what we currently have. Note that if we remove the restriction to encapsulate other apps this could even work with what we have right now. Best, Antonio * They're loaded remotely (aka in another process). * If the app/url referenced on the iframe is already loaded, don't load it again, just return a window object that points to the already loaded URL. * They don't have opener (which wouldn't make sense anyway since they can be opened from several places at the same time) * And the window object created by the iframe allows postMessage With an example: * On the client app HTML: <iframe id="settingsService" mozservice src="app://settingsservice.gaiamobile.org" ></iframe> (on the client app code)... ... settingsService.postMessage(settingINeed, "app://settingsservice.gaiamobile.org"); ... * On the service app: .... window.addEventListener("message", handleMessage, false); .... // Called sometime after postMessage is called function handleMessage(event) { // We can check here the sender, the data, or any combination thereof // So for example, originA could only be allowed to read settingA while // originB could be allowed to read and write settingB, and read only settingC if (!allowedMessage(event)) { return; } // At this point we know the petition can be served, go ahead and serve it. getSetting(event.data).then(settingData => event.source.postMessage(settingData, event.origin)); } As I said, it's easily told (and IMHO webby enough since we don't actually need any new API, just a new kind of frame which can be just ignored by everybody else) but harder to implement. WDYT? Fwiw, this is just a different API design. I'm just exposing the way I would like to explore it with the new Gaia architecture. The first focus should really be on: "is there a chance that those kind of services exists ?" Thanks for launching this discussion. Vivien. [1] http://hg.mozilla.org/mozilla-central/diff/2a8fd75b667f/dom/apps/src/PermissionsTable.jsm ________________________________ 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]<mailto:[email protected]> https://lists.mozilla.org/listinfo/dev-b2g _______________________________________________ dev-b2g mailing list [email protected]<mailto:[email protected]> https://lists.mozilla.org/listinfo/dev-b2g ________________________________ 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
