Think of a way to implement server-to-client push notification

[michielbdejong]

This came up on the mailing list. HTTP doesn't really allow this, but I think HTTP/2 does? We could also use WebSockets or HTML5 push notifications somehow.

[untitaker]

This one is easiest: https://en.wikipedia.org/wiki/Server-sent_events

[untitaker]

Concretely: https://html.spec.whatwg.org/multipage/comms.html#server-sent-events

No extra port needed, very simple data format, and JS supports it out of the box.

[ghost]

Rationale / Use-case?

[untitaker]

Right, the direct archive link would be useful.

Instant sync, also etherpad-like apps would be possible (though still hard).

[raucao]

How about just defining the format and leaving the transport to the app/client developer? That way we could have an API in rs.js for basically "got this from server, do sth with it".

Edit: that was just a quick thought. Already seeing issues with not defining the transport right now. ;)

[untitaker]

To clarify, "server-to-client" notifications means something like "fs events" to me (since remoteStorage is an FS), not a general-purpose event system where every client can "register" events.

[raucao]

A push notification is not really a normal event. It usually means you're not listening actively, and only waiting for the push notification to arrive (e.g. in a ServiceWorker), before your app activates and does sth with it. No?

[untitaker]

Iunno, I thought it'd be basically the same thing, with the difference that in your case you'd just "subscribe to all events"

[raucao]

Not really. For push notifications you usually just subscribe to the Important Stuff™. Not sure what that would even means in RS context, though.

Edit: so yes, SSE seems like it could bring more value, replacing those pesty sync requests somewhat.

[untitaker]

In the context of RS I thought you could subscribe to any item (folder/file) and listen to etag changes.

In particular you'd send a request to its URL with a special header (similar to Connection: keep-alive), and the server would write to the response if the etag changes (as defined in HTTP SSE)

This would allow for "instant" re-sync of a tree without much additional complexity.

EDIT: Just realized that this sort of protocol is not RS specific, since it only depends on etags it could be its own spec.

[raucao]

This would allow for "instant" re-sync of a tree without much additional complexity.

... on the client side. It's considerable complexity on the server side of course, because you need to do things asynchronously and keep sessions open for all connected clients at all times.

[raucao]

In reality we'd probably have like one common node.js app that you can hook into, but which you have to deploy in addition to your normal RS server.

[untitaker]

... on the client side. It's considerable complexity on the server side of course, especially because you need to do things asynchronously and keep sessions open for all connected clients at all times.

This is a problem with any possible "push notifications" implementation, unless you use a separate piece of software.

If you're going to have a single node.js app, we don't even need to properly spec the serverside.

[raucao]

If you're going to have a single node.js app, we don't even need to properly spec the serverside.

The API towards the server for subscribing has to be defined, of course. Also, discovery of such an endpoint.

[untitaker]

Either way this might be a candidate for its own RFC. Could we have a label for those?

[raucao]

Either way this might be a candidate for its own RFC. Could we have a label for those?

👍