On Di, 2015-03-03 at 21:28 -0800, Lance Stout wrote:
> The goal for the XEP is to let an XMPP server notify the App Servers for the
> user's apps when something interesting happens. What those apps do once
> notified
> is up to the app's purpose and implementation. Of course, the common case we
> expect is for those apps to in turn publish a push notification to the user's
> devices which have the app installed. But that is not actually required, and
> the fact that multiple apps may forward their notices via the same third-party
> mechanism to user devices is only coincidence.
>
> It comes down to that apps have purpose and will do different things. For
> example, say that I have two apps which both happen to use Ubuntu Push to send
> data to my device. One is a typical general IM client. The other is a video
> call
> app. The App Server for the video call app will only send data through Ubuntu
> Push when it receives a notification that includes Jingle data. The App Server
> for the general IM client might only send data through Ubuntu Push when chat
> message data was included in a notification, and it could also keep track of
> all
> the chat message notifications it received for me during a day and send me a
> summary email every evening of things I might have missed.
>
> Forcing those two apps to use the same App Server will not work, because their
> App Servers are different, even if they do some things in common. Even if
> they did the exact same things now, that is not guaranteed to be true forever.
> Apps change, gain and lose features. App Client and App Server necessarily
> need to be kept in sync.
>
> That said, what you do want to do to preserve decentralization is to let the
> user of an app run their own instance of the App Server. Once you allow that,
> it remains an implementation detail how the App Client discovers and
> registers
> with the App Server.
You are right, I mainly thought of typical IM apps doing my
implementation. But I'm convinced a careful implementation with my
approach can also fit more special applications (more below).
No matter if app server and xmpp server are merged or not you brought up
an important aspect. If the app server shall be able to pick only
specific published items and convert them into a proprietary push
notifications (ppn), there needs to be information in the published item
it can base its decision on. I think criteria for these decisions are:
- incoming stanza type (message, iq, presence)
- namespaces of the stanza's children
So these criteria must be included in the items the xmpp server
publishes, e.g.
<iq type='set'
from='u...@example.com'
to='push-5.client.example'
id='n12'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='yxs32uqsflafdk3iuqo'>
<item>
<notification xmlns='urn:xmpp:push:0'>
<x xmlns='jabber:x:data'>
<field var='FORM_TYPE'>
<value>urn:xmpp:push:summary</value>
</field>
<field var='stanza-type'>
<value>iq</value>
</field>
<field var='child-xmlns'>
<value>urn:xmpp:jingle:1</value>
</field>
<field var='last-sender'>
<value>juliet@capulet.example/balcony</value>
</field>
</x>
</notification>
</item>
</publish>
</pubsub>
</iq>
If a client only wants to be notified if jingle stanzas arrive, it could
configure its xmpp server to publish only if the child-namespace
criterion is met:
<iq type='set' id='x42'>
<enable xmlns='urn:xmpp:push:0'
jid='push-5.client.example'
node='yxs32uqsflafdk3iuqo'>
<x xmlns='jabber:x:data'>
<field var='FORM_TYPE'>
<value>urn:xmpp:push:0#options</value>
</field>
<field var='child-xmlns'>
<value>urn:xmpp:jingle:1</value>
</field>
...
</x>
</enable>
</iq>
I picked up your idea of an extra data form for configuring the xmpp
server. The reason for configuring the xmpp server in this way would be
of economic nature (only publish what is relevant for the app / app
server). To configure the server to also publish messages, we would add
value 'jabber:client' (and use XEP-0352 to protect us against the
presence / chat state storm).
Now to my merged servers approach. My implementation aims to notify the
app on events, so no email sending ;-) If an app needs an app server
with more features it can register at an app specific server and still
use the xmpp server part of my implementation.
With the client defining the namespaces of incoming stanzas to be
considered there's a dynamic possibility for the client to define the
push events, at least up to a certain degree. An alternative to define
them for my approach would be to send a list of namespaces when
registering but I like the configuration in the enable-iq more.
> So from my point above, in this case you would not search for an XMPP Push
> Service for Ubuntu Push. You would search for an XMPP Push Service for your
> app.
> This is an interesting idea to pursue. Perhaps we need to define how to create
> disco#info identities for this? Would this be a follow-up XEP or defined here?
>
> <iq type='result'
> from='my-app-server.montague.example'
> id='x13'>
> <query xmlns='http://jabber.org/protocol/disco#info'>
> <identity category='pubsub' type='push' />
> <identity category='app-server' type='my-cool-app-name' />
> </query>
> </iq>
>
> This needs more implementation experience to hammer out.
I'm always puzzled when I look at service discovery. Your example would
require the client to make multiple disco requests, wouldn't it? the
first would be an items query to its xmpp server to get a list of
associated services and then it would send an info request to each
service. In my opinion it's only necessary to find app servers for
clients using services without a restrictive authorization requirement
(at the moment there's only Ubuntu push).
If you don't want a per-push-service hostname discovery in the XEP
because the discovered server might not fit all clients using that
push-service, how about something like this:
<iq type='get'
from='ro...@montague.net/orchard'
to='montague.net'
id='items3'>
<query xmlns='http://jabber.org/protocol/disco#items'
node='urn:xmpp:push:0#ejabberd-push/ubuntu'/>
</iq>
<iq type='result'
from='montague.net'
to='ro...@montague.net/orchard'
id='items3'>
<query xmlns='http://jabber.org/protocol/disco#items'
node='urn:xmpp:push:0#ejabberd-push/ubuntu'>
<item jid='push-up.montague.net'/>
</query>
</iq>
Not beautiful but it tells the client what it can expect. Maybe
something better comes to my mind.
Christian
