Consider how we will implement Web Push
banks opened this issue · 7 comments
There is a new standard being drafted that is the future of push on the web.
We should be one of the first open source server options to support this.
https://martinthomson.github.io/drafts/draft-thomson-webpush-http2.html
Uses HTTP/2 primarily as transport so with go1.6 on the horizon this should easy to support. Chrome supports a restricted version that only works with GCM for now but Firefox Nightlies are already implementing support.
After I clarified with the authors on the mailinglist (resulting in w3c/push-api#179) it is apprent that Web Push will NOT be a suitable replacement for WebSockets or other transports in Centrifugo.
But I still think there is a lot of value in considering supporting it as an additional feature such that Centrifugo remains a complete solution for both in-page and out of page updates. We'd also be one of the first open source implementations I guess which might be a useful thing for profile of the project.
One downside is that it requires HTTP/2 push promises and go1.6 http integration does not yet support push.
It is certainly possible to implement push - the http2 lib in golang has the necessary protocol support, just the net/http integration does not expose it. I'm considering opening an issue on golang to see if it will be considered for support.
an additional feature such that Centrifugo remains a complete solution for both in-page and out of page updates
It would be ideal for our use case. Single solution for all in/out of page updates. SSE might be a consideration too, but I don't want to add more feature bloat. :)
@banks @jeberly I have doubts that draft promoting specification for web push server will be approved in near future - I don't understand the motivation behind this - allowing any server to be web push server means that every site will create separate connection to separate domains in Service Workers. Is this reasonable to have? When Firefox and Chrome have its own web push servers (GCM or Mozilla’s Web Push service) it's reasonable because this could be single connection for all sites.
I'm not sure about it being approved soon, but the standard is worthwhile even if Firefox and Google have centralised services. The fact they are all a standard and interoperable is important.
In practice we already have every major site implementing their own push stuff - for "online" messaging, that is the reason Centrifugo exists after all. And even if Google and FF have free centralised services there will always be people who have use cases that don't fit or need more control.
My understanding (might be out of date) is that Google has an existing non-compliant service which is experimental but FF and other browsers are pushing for this standard exactly so they don't have to run their own proprietary service to be feature compatible with chrome - let publishers bear the cost of service infra but still have feature parity with Google/chrome who can afford to run huge services for free.
I think the standard is interesting regardless, but I agree it's still too early for this to be essential. The biggest opportunity I see would be if we are one of a very few open source implementations available if/when it does become a more widely used tech it would be cool.
I also saw movement on some of the blocking issues in golang recently so it might be feasible soon. I think it would be possible now actually just with more customisation needed to http2 handler.
On 3 Jun 2016, at 08:30, Alexandr Emelin notifications@github.com wrote:
@banks @jeberly I have doubts that draft promoting specification for web push server will be approved in near future - I don't understand the motivation behind this - allowing any server to be web push server means that every site will create separate connection to separate domains in Service Workers. Is this reasonable to have? When Firefox and Chrome have its own web push servers (GCM or Mozilla’s Web Push service) it's reasonable because this could be single connection for all sites.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
Yep, I agree that overall this is a good feature. Just as far as I understand push-api was invented with device battery life in mind and having lots of connections to various servers in background don't fit well into this paradigm. But maybe in practice this won't be a problem? Anyway let's watch on the spec draft, just discovered another link with more actual version
+1
Not sure if the status of this draft but I’ve not seen anyone asking for or excited about this protocol so let’s close unless someone has a really strong motivating case where an alternative isn’t a simpler option.