[jdev] notification server
Roberto Ostinelli
I need to build a notification server for an m2m application, where events are being pushed every few seconds to a large group of JID.
At first, I was considering PubSub, then I realized that all messages are actually stored on the server as content, which is something I obviously do not want (once the notifications have been sent, I do not want to store them).
Therefore, is XEP-0060 the extension I'm looking for, or should I consider something else?
Thank you,
r.
_______________________________________________
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: JDev-uns...@jabber.org
_______________________________________________
Matthew Wild
> Dear list,
>
> I need to build a notification server for an m2m application, where events are being pushed every few seconds to a large group of JID.
>
> At first, I was considering PubSub, then I realized that all messages are actually stored on the server as content, which is something I obviously do not want (once the notifications have been sent, I do not want to store them).
>
> Therefore, is XEP-0060 the extension I'm looking for, or should I consider something else?
It's covered, see: http://xmpp.org/extensions/xep-0060.html#events
However that section is rather over-complicating the matter in my
view. The implementation you use should allow you to simply configure
the node with: persist_items=0, max_items=0, cache_last_item=0 (actual
config options may vary) to achieve the kind of node you want.
Regards,
Matthew
Roberto Ostinelli
Roberto Ostinelli
Matthew Wild
> after digging into this..
>
> what would be the advantage into using pubsub instead of a custom written
> (and much simpler) protocol? it seems that i need to strip out a lot of the
> functionalities I'd never need (item persistence, complex authorization
> mechanism, writing to disk,...), not counting bigger payloads and
> collections often not supported on real servers (ejabberd for instance).
>
You don't need to "strip out" - you just don't use features you don't need.
Let's consider you not using pubsub. It sounds like, for the use-case
you have, you just want to broadcast a fixed message to a set of JIDs.
So there are several problems you need to solve. Something somewhere
has to actually do the broadcasting, looping through a list of JIDs,
and sending a message. The second problem is managing the list - it
has to come from somewhere, and get to the broadcaster. Finally, you
have to get the message to broadcast to the broadcaster (and if this
is done over XMPP, ensure the sender has the permission to publish,
etc.).
XEP-0060 at its heart is built around solving these core problems. It
also has various other (optional) features that are often also
required in these kind of situations bolted on top.
It's certainly possible to not use XEP-0060. There was a XEP that
never really got anywhere that was based around the idea of solving
the first two of the problems (broadcast and list managing):
http://xmpp.org/extensions/inbox/repeaters.html .
Finally you could just implement this in a component. If you have the
list of JIDs already in a database, and your messages are originating
from outside of XMPP, XEP-0060 doesn't offer much you don't already
have and this seems like a very decent option. The main concern would
be if you have a large number of JIDs to send to, it isn't
spectacularly efficient for the component to send the same message
over the wire to each one sequentially - it would be better to let the
server handle the broadcast. http://xmpp.org/extensions/xep-0033.html
can sort of do this (there are plugins for several servers for it).
Summary:
For XEP-0060: Off-the-shelf support in client libraries and servers,
does everything you need already (and more you might need later on),
possibly more optimised in the server.
Against XEP-0060: Basically a custom approach can be streamlined to
your workflow and more tightly integrated with your system.
Hope this helps,