On Thu, Feb 26, 2015 at 2:50 PM, ANTONIO MANUEL AMAYA CALVO < [email protected]> wrote:
> > On 26 Feb 2015, at 14:31, Vivien Nicolas <[email protected]> wrote: > > > > On Thu, Feb 26, 2015 at 12:02 PM, Antonio Manuel Amaya Calvo < > [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). > > Note that Client/Server are pure app logic as I mentioned and they use postMessage in the background. > > - 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. > Well. I assume that different phones from different manufacters may ship similar Services but their inner app may used different urls. > > > - 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. > A new kind of <iframe> is a kind of new API :) > > 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 calledfunction 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] >> https://lists.mozilla.org/listinfo/dev-b2g >> >> > _______________________________________________ > dev-b2g mailing list > [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
