Only send/receive minimum data when polling

[PVince81]

Imagine a scenario where someone has 10+ notifications. We poll every 30 seconds so every 30 seconds the whole 10 notifications will be returned, wasting bandwidth.

As long as we have polling we should at least switch to a more efficient way:

• client must send etag when requesting notifications
• server checks etag against new etag:
  • if same, return 304 not modified
  • if different, return the new contents

All clients should also be adjusted for that.

@DeepDiver1975 @butonic @michaelstingl

[PVince81]

also cc @jvillafanez

[PVince81]

Etag could be computed by the server based on the sorted list of notification ids.

The etag must be returned by the server for the GET request.

[DeepDiver1975]

the etag is already sent from the server to the client - https://github.com/owncloud/notifications/blob/master/lib/Controller/EndpointController.php#L105

[jvillafanez]

I think all notifications have a timestamp, so if the client sends a timestamp during the polling the server can return all the notifications from that point onwards.

So if the client doesn't send a timestamp, the server returns all the notifications (with pagination if needed). The client can figure out what is the last notification based on the timestamp of each notification, and use that timestamp for the next request.

As long as the notification timestamp is indexed, even though we'll need to hit the DB always, the performance should remain constant without too much stress in the DB

[DeepDiver1975]

The server knows which notification have been sent - the polling endpoint only returns the delta. Need to search the code to fine out how.

[PVince81]

From looking at the JS code it seems the jquery call is very simple and doesn't send neither etag nor mtime, so maybe it's not using the delta approach in the web UI: https://github.com/owncloud/notifications/blob/master/js/app.js#L324.

We should then adjust the web UI to make use of that.