Temporary subscriptions for 'everything', to enable 'live updates' (discussion)

[bengtan]

We want to implement so-called 'live updates' for everything (as much as possible) in the app (where 'live updates' is roughly synonymous with asynchronous updates).

I've been thinking about this, and the conclusion I've come to is that ... the client needs to inform the server of all the objects/bots/users/etc that it is interested in (ie. interesting in receiving async/live updates for, so it can refresh them if displayed to the user).

There is no way for the server to intelligently guess what objects the app has displayed to the user. (And we are not sending async updates of everything to everyone.)

XMPP provides a mechanism for a client to 'register' that it is interested in an object. It's called 'directed presence'. Essentially, it's a temporary subscription that lasts for as long as the client remains online. When a client goes offline, there's some magic at the XMPP server which automatically tears down the temporary subscriptions.

So I'm thinking a pattern like this:

o App shows a user profile to the user. o App sends directed presence to the user profile so that, if the user profile changes, the app is informed.

or

o App shows a bot profile to the user o App sends directed presence to the bot so the app is informed of any future changes to the bot

or

o App shows 5 new HS items to the user o For each HS item, app sends directed presence to the bot (if there is one) referenced by the HS item.

The app sends directed presence for each object that it has displayed to the user. This might seem like a lot of work, but it's the only way (I can think of) for the app to be kept informed.

Also, yes, this means there are a lot of directed presence stanzas being sent but the client can batch them up and send them as multicast. So if the app shows 5 new HS items which are bot shares, it can send a single multicast directed presence to the server, and the server routes that to the 5 bots.

[bengtan]

cc @bernard @toland @aksonov @southerneer

[bengtan]

Note to self (after discussion with Phil and Bernard):

Not everything has to be real time. If we can agree that some things can be:

• non real time (ie. bot description field)
• semi real time (ie. bot subscriber count)
• near real time (ie. HS or chat messages)

then it's more feasible to use directed presence only for traffic which needs to be real time, and semi- or non- real time for everything.

Need to talk with Steve and Becky and manage expectations of what needs to be real time.

Also, relaxing the 'everything is real time' assumption (that I made) can help in reducing battery usage for cellular traffic.

[toland]

Relevant to this discussion: A talk titled "Live APIs with GraphQL Subscriptions" from ElixirConf 2017.

[bengtan]

Closing for a combination of reasons:

• This was a discussion that didn't proceed further.
• It's really old and partially obsolete.
• It's partially, or substantially, superseded by graphl subscriptions.