976789 - [meta] see what parts, if any, of unlanded SimplePush work is required for loop_mvp

Status: RESOLVED WONTFIX

(Hello (Loop) :: Client, defect, P1)

Description

[Dan Mosedale (:dmosedale, :dmose)]

Bug 857464 and its dependents may not be necessary for our MLP at all. There's a theory that it's already available to chrome, and that we could use it there.  

First step is to find out from dougt if that's true and what exactly the API is.

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

Just had a long discussion with dougt, and it sounds like we will in fact need much of the code in the bug 857464 dependency tree, but that much of it's in progress. 

As a next step, he's going to mail me or post here more code/context about what all we would need to do.

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

This is currently believed to be the thing that's most viable to scale, so the intent is to go forward with it.  However, we're still waiting on a needinfo for more details.

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

dougt

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

Heh, whoops.  I was starting to say that my impression from dougt was that it might be possible for us to get a quick patch in order to things moving quickly, but he wondered what API would be most useful for that.

Given our current approach of running SocialAPI panels with chrome privs, and discussions with various folks, it's not obvious to me what we actually want here.

Comment 5

[Mark Banner (:standard8)]

I think it would make sense that if we have chrome privs in SocialAPI then we use a gecko service or javascript module which would be a listener for the push notifications that we want. As it is a service, it would be available regardless of which windows/panels had already been opened.

Whilst we could use the social api background worker, this would add another layer of postMessage/onmessage event handling, that I don't think is necessary.

Comment 6

[Alexis Metaireau (:alexis)]

Would that be a potential solution to wake up the SocialAPI worker when Firefox receives a simple push notification, so we avoid running the worker when we don't need it?

(In reply to Mark Banner (:standard8) from comment #5)
> Whilst we could use the social api background worker, this would add another
> layer of postMessage/onmessage event handling, that I don't think is
> necessary.
+1 for less message proxying.

Comment 7

[Doug Turner (:dougt)]

nikhil is sending what he has.

Comment 8

[Dan Mosedale (:dmosedale, :dmose)]

nsm was kind enough to send along the following, posted here with his permission:


https://tbpl.mozilla.org/?tree=Try&rev=8977bfe99b0a

Here is a build of Firefox that supports the following:
- ServiceWorker registration (no unregistration). If you want to
unregister, just delete the file serviceworkerstore.json from your
profile directory.
- Enables push notifications
- Sends Push notification to serviceworker registered for the domain.

Right now it's specifically push only, do let me know if you need other
events and I can show you guys how to do it. For a look at how to send
events, see dom/push/src/PushService.jsm, where you get an instance of
ServiceWorkerManager and sendEvent() to it.

While all the tests on tbpl have failed, that is because i have one bad
line in my code. My local build works, so it shouldn't be a problem. If
it does crash, In dom/workers/ServiceWorkerManager.cpp, comment out the
RemoveObserver() line from the ServiceWorkerManager::Observe().

Here is a sample application:
https://github.com/nikhilm/simplepush-test-app/tree/serviceworker

Let me know if there are any problems.

Comment 9

[Mark Banner (:standard8)]

This is part of needed work for bug 1002414 / bug 1013251

Comment 10

[:shell escalante]

we do not want to rely on the existing Push implementation in desktop - so need to continue to use our custom implementation.  network API we are using will be available, but desktop PUSH is changing to evolving w3c spec.

Comment 11

[Mark Banner (:standard8)]

(In reply to sescalante from comment #10)
> we do not want to rely on the existing Push implementation in desktop - so
> need to continue to use our custom implementation.  network API we are using
> will be available, but desktop PUSH is changing to evolving w3c spec.

As discussed with Adam, we're not using the Push implementation in desktop for now due to expected significant changes to the push api before it is made public, so for now we're going to continue using our own impl.