Re: Removing hacks in favor of a cross-application communication API

[JOSE MANUEL CANTERA FONSECA]

El 22/02/13 02:01, "Kevin Grandon" <kgra...@mozilla.com> escribió:

>If there is someway this could handle our Facebook mess for the
>communications mega-app, that would be nice :)

Yes, it would make things easier and cleaner in the Facebook integration
side, although it may have perf problems we should be careful with.

> I think the goal would be to take all four apps out of communications,
>and have them all as their own individual apps.

Well, that may have other implications specially how the dialer and
contacts apps work together,

>
>Also - postMessage is a pretty nice API. Is it possible to just make that
>work? Even if it has to behave differently under the hood?

That would not be a clean nor a good solution. I think HTML5 provides
other mechanisms such as MessageChannel, that can be studied, or create a
new one if none satisfies our requirements. The best way to start would be
to think of use cases for the API.

>
>----- Original Message -----
>From: "Fabrice Desre" <fab...@mozilla.com>
>To: dev-...@lists.mozilla.org
>Sent: Thursday, February 21, 2013 4:49:21 PM
>Subject: Removing hacks in favor of a cross-application communication API
>
> Hi All,
>
>We want to get rid of a couple of shortcuts we had to use to get v1.x
>out of the door in time:
>- the infamous mozChromeEvent/mozContentEvent that allows us to
>communicate from the system app to gecko.
>- the abuse of settings listeners as a cross-application communication
>channel.
>
>I can easily get a list of the mozXXXEvents, but I'd like input from
>gaia devs to be sure we don't miss a use case for the later one. I'm
>sure we use that to notify update status between the settings app and
>the system app, but there are probably others.... don't be shy, we must
>remove them all!
>
>I chatted briefly with Jonas and based on all the use cases he promised
>to design a nice API.
>
> Fabrice
>--
>Fabrice Desré
>b2g team
>Mozilla Corporation
>_______________________________________________
>dev-gaia mailing list
>dev-...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-gaia
>_______________________________________________
>dev-gaia mailing list
>dev-...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-gaia
>



________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

[Salvador de la Puente González]

Hello everybody

First, I would want to point a user case I found in Cost Control application: as I have several views (the application and the widget in utility tray), sometimes I need to communicate something from one view to another. I could use a listener on settings but trying to not abuse this hack, I'm using a localStorage event, writing a 'sync' value to the database, the event notify all window objects able to access the LocalStorage.

On 26/02/13 09:34, JOSE MANUEL CANTERA FONSECA wrote:

Also - postMessage is a pretty nice API. Is it possible to just make that
work? Even if it has to behave differently under the hood?



That would not be a clean nor a good solution. I think HTML5 provides
other mechanisms such as MessageChannel, that can be studied, or create a
new one if none satisfies our requirements. The best way to start would be
to think of use cases for the API.

Related with use cases such as:

* Import / export contacts
* Import / export messages
* Notifications hubs / aggregators (Twitter + Facebook + LinkedIn...)

I would want to propose an extension for `app://` protocol to implement `content providers`. Briefly, when you are accessing a `content provider` URL, this does not return until a `HTTPResponse` object is dispatched from the target URL or timeout. This object fakes a HTTP response allowing the communication to be transparent. The actor interested on content could ask for content providers covering some "MIME" type.

It could be implemented as follows:

* Add 'content providers' URL to the manifest. It includes a MIME type like field and some meta
* Use var response = new HttpResponse(code[, data]); response.send()
* Use navigator.getContent(mimetype[, arguments]) to ask the browser agent for registered content providers

Hope it helps!

[Fabrice Desre]

Hey José,

On 02/26/2013 12:34 AM, JOSE MANUEL CANTERA FONSECA wrote:

> That would not be a clean nor a good solution. I think HTML5 provides
> other mechanisms such as MessageChannel, that can be studied, or create a
> new one if none satisfies our requirements. The best way to start would be
> to think of use cases for the API.

My original message was asking for current use cases, not solutions :)
But if there are potential use cases, you're welcome to contribute!

[Fabrice Desre]

Hey Salvador,

On 02/26/2013 02:36 AM, Salvador de la Puente González wrote:
> Hello everybody
>
> First, I would want to point a user case I found in Cost Control
> application: as I have several views (the application and the widget in
> utility tray), sometimes I need to communicate something from one view
> to another. I could use a listener on settings but trying to not abuse
> this hack, I'm using a localStorage event, writing a 'sync' value to the
> database, the event notify all window objects able to access the
> LocalStorage.

localStorage!!?? This is the worst thing to use, since it's doing main
thread blocking I/O... I though we removed all of the uses after the Sao
Paulo work week, looks like it came back. Time to land bug 787487 I guess.

[Salvador de la Puente González]

Hello Fabrice

On 26/02/13 18:09, Fabrice Desre wrote:
> localStorage!!?? This is the worst thing to use, since it's doing main
> thread blocking I/O... I though we removed all of the uses after the Sao
> Paulo work week, looks like it came back. Time to land bug 787487 I guess.

Talking with Vivien in the last working week in Madrid we agree this was
the best solution instead of communicating via Settings.

If you remove localStorage then I would need an alternative and this
seems to be the Settings solution.

What do you think?

Thanks!

[Dietrich Ayala]

Yes, please land that asap :) We should consider emitting warnings for
all web content when localStorage is used.

Salva, you should use DJF's asyncStorage lib instead maybe? It's as
easy to use as localStorage, but doesn't block the main thread.

On Tue, Feb 26, 2013 at 9:09 AM, Fabrice Desre <fab...@mozilla.com> wrote:
> Hey Salvador,
>
> On 02/26/2013 02:36 AM, Salvador de la Puente González wrote:
>> Hello everybody
>>
>> First, I would want to point a user case I found in Cost Control
>> application: as I have several views (the application and the widget in
>> utility tray), sometimes I need to communicate something from one view
>> to another. I could use a listener on settings but trying to not abuse
>> this hack, I'm using a localStorage event, writing a 'sync' value to the
>> database, the event notify all window objects able to access the
>> LocalStorage.
>

> localStorage!!?? This is the worst thing to use, since it's doing main
> thread blocking I/O... I though we removed all of the uses after the Sao
> Paulo work week, looks like it came back. Time to land bug 787487 I guess.
>

> Fabrice
> --
> Fabrice Desré
> b2g team
> Mozilla Corporation

[Dale Harvey]

IndexedDB doesnt support change notifications :(

[Salvador de la Puente González]

Hello everybody

Sorry, I think I did not explain myself clearly. The problem is not
storing data. I already use asyncStorage for that purpose.

The problem is using the `storage` event to communicate all views
something in IndexedDB has changed. I use something like:

localStorage['sync'] = 'nextReset#' + Math.random();

To warn all views that nextReset entry in IndexedDB has change. I need
the random mark because the event is only triggered when the key changes.

Anyway, I'm reviewing the application in order to remove it at all due
to latter changes that make it unnecessary.

Do you understand the communication issue?

Thanks.

[Julien Wajsberg]

When optimizing the startup for the E-mail app with Vivien, we measured
that using localStorage instead of IndexedDB-with-asyncStorage was about
300ms faster.

(At the end, we're using cookies).

[Fabrice Desre]

On 02/26/2013 10:14 AM, Julien Wajsberg wrote:
> When optimizing the startup for the E-mail app with Vivien, we measured
> that using localStorage instead of IndexedDB-with-asyncStorage was about
> 300ms faster.

It's not just about being fast, it's about keeping the UI responsive to
user input. I would rather not block and wait 2 seconds than block
during 1 second.

[Julien Wajsberg]

Le 26/02/2013 19:19, Fabrice Desre a écrit :
> On 02/26/2013 10:14 AM, Julien Wajsberg wrote:
>> When optimizing the startup for the E-mail app with Vivien, we measured
>> that using localStorage instead of IndexedDB-with-asyncStorage was about
>> 300ms faster.
>
> It's not just about being fast, it's about keeping the UI responsive to
> user input. I would rather not block and wait 2 seconds than block
> during 1 second.

Yep I agree with you in general.

In this specific use case, we were using one get at startup (no user
input yet anyway), and one set when adding/removing account (so hardly
the main UI).

[David Flanagan]

On 2/26/13 10:14 AM, Julien Wajsberg wrote:
> When optimizing the startup for the E-mail app with Vivien, we measured
> that using localStorage instead of IndexedDB-with-asyncStorage was about
> 300ms faster.
>

> (At the end, we're using cookies).
>
> Le 26/02/2013 19:02, Dietrich Ayala a écrit :
>> Yes, please land that asap :) We should consider emitting warnings for
>> all web content when localStorage is used.
>>
>> Salva, you should use DJF's asyncStorage lib instead maybe? It's as
>> easy to use as localStorage, but doesn't block the main thread.
>>
>>

But, as Julien notes, asyncStorage does depend on IndexedDB, and
spinning up IndexedDB to read a small amount of configuration data is a
pretty expensive operation.

Fabrice: any chance that the new get-rid-of-hacks API could include
private storage for apps in a gecko-based db that is already running?

David

[Andrew Sutherland]

On 02/26/2013 01:14 PM, Julien Wajsberg wrote:
> When optimizing the startup for the E-mail app with Vivien, we measured
> that using localStorage instead of IndexedDB-with-asyncStorage was about
> 300ms faster.

But we ended up using a cookie, which was much less evil and even faster!

Andrew

[David Flanagan]

Still blocks the main thread, though right? But for a shorter time? Is
this a performance pattern for Kyle?

> Andrew

[Salvador de la Puente González]

Hello everybody

> Anyway, I'm reviewing the application in order to remove it at all due
> to latter changes that make it unnecessary.

I reviewed the code and I need a mechanism to send a `sync`signal
between bugs. So, what do you recommend? Avoid localStorage and replace
it by the settings observer solution?

Any better approach?

Thanks.