Hi,
That was after seeing a ProcessOne conference video about this that I
got the idea to write a XEP
(http://www.process-one.net/en/blogs/article/sea_beyond_2011_talk_2_christophe_romain_karim_gemayel_on_pubsub_and_distri).
ProcessOne defined a way to manage such notifications entirely server-side, as
you think it is better. And I agree.
But actually, there are no way to do it server-side with Pubsub: no XEP
exists for that, and no home-made server patches exists for that. We
need something which works with the actual standards, and it actually
works (implemented in Jappix dev. version for instance).
That's why we would better work on a clean way to store and retrieve
notifications first, and then, standardize a way to do it entirely
server-side.
Cheers,
Valérian Saliou
Jappix founder
---
On Wednesday, June 01, 2011 10:37:07 AM XMPP Extensions Editor wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Notification Inbox
Abstract: This document defines a protocol to manage a notification
inbox
for pending events.
URL: http://www.xmpp.org/extensions/inbox/notification-inbox.html
The XMPP Council will decide at its next meeting whether to accept
this
proposal as an official XEP.
Good to see people are thinking about this. However, I somewhat
disagree with
the approach of remote services directly writing into a user's inbox.
My plan (which, admittedly, is not fully realized anywhere yet) is that
entities may monitor a remote pubsub node via normal subscriptions, and
one of
these entities could be some sort of tracking service that monitors the
node
while the user is offline (we can call this inbox, but I prefer
tracking
service in order to stay a little more generic). Additionally, for
cases
like tagging a user whose tracking service is not yet subscribed to the
node,
the remote service can send an unsolicited notification.
The above approach keeps remote services simple. They don't need to
care what
may count as an inbox notification and what may not. They simply emit
regular
pubsub notifications. Interpretation of these pubsub notifications by
the
tracker into an inbox-like facility and beyond (e.g. sending emails,
SMS, etc
to the user) remains a separate issue.
So, maybe this XEP could be a definition of how a tracker offers inbox
management to a user. But it would not necessarily define how the
tracker
consumes remote pubsub notifications and converts them.
Justin
