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.
- 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.
- 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.
* 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
