On Di, 2015-03-10 at 01:27 -0700, Lance Stout wrote:
> I may need to add additional clarifying language to the XEP then. Enabling
> and disabling as defined is for the bare JID account level. However,
> servers could keep track of which services a particular resource connection
> enabled and use that information to do more intelligent notifications.
>
> The defined workflow is that when the XMPP server detects something
> interesting
> happened, then it has a set of JID+node endpoints that can be informed of that
> interesting event via pubsub publishes. We could let the server have the
> option
> to pick which of those JID+node combos it will publish to, but there is not a
> defined way to choose any particular subset. However, there are options
> available to
> pick from, for example:
>
> - Was the interesting event associated with a particular resource that also
> had
> enabled push services? Send the publish to only those services.
> - Are there push services for a user which have not been enabled by any of
> the
> user's current online sessions? Send the publish only to those services.
> - Publish to all enabled services regardless of if the user has any online
> resources.
>
> I expect that the XEP will expand to cover this topic once we have some more
> implementation experience on what works well in practice.
>
> Of course, what defines interesting (and the levels and kinds of interesting)
> is
> left to the server implementation and to future XEPs, but there are a lot more
> potential things than just offline messages.
Thanks for clarifying. Do we allow a client to send an enable stanza
before resource binding then? We should not, if we want to allow the
first two options you mentioned.
For my implementation I decided to use a little trick for now in order
to reduce complexity: Potentially "interesting things" are defined by
stream management storing a stanza for later delivery. Important detail:
When a push-enabled client enters the waiting-for-resumption state
(a.k.a. zombie state), because stream management recognized the
connection was closed, the push-module overwrites the resumption timeout
(typically something like 5 min) with a long time span (e.g. 100 days).
Interesting things thus happen only for clients having stream management
resumption enabled. That's a little sad for clients without that feature
but in my view has some advantages:
- stream management may only be enabled when resource binding is
complete, so all the potentially interesting stanzas are directed to a
full jid. So the responsibility to route stanzas is delegated to the
server's routing algorithm and might be configured by XEP-0354 in the
future.
- filtering mechanisms like CSI can be used (not possible if client is
offline)
- client stays in an available state, presence information is visible to
presence subscribers (e.g. another resource might want to know the
priority to become more / less available)
more details I came across:
The XEP defines the push notification field last-message-body. RFC 6120
says:
"Multiple instances of the <body/> element MAY be included in a message
stanza for the purpose of providing alternate versions of the same body,
but only if each instance possesses an 'xml:lang' attribute with a
distinct language value"
Quite a rare case I think, should the server just pick the first body or
should it include all bodies like this:
...
<x xmlns='jabber:x:data'>
<field var='FORM_TYPE'><value>urn:xmpp:push:summary</value></field>
<field var='last-message-body'>
<option label='de'><value>Warum bist du Romeo?</value>
<option label='en'><value>Wherefore art thou Romeo?</value>
</field>
</x>
...
Is there a reason why jingle events (like in the old version) are not
included in the field list?
Could a server shutdown be a push event? Otherwise the server should
store the list of enabled clients in persistant storage. I don't know if
that's something for the XEP to mention.
Christian
