Newsletters over XMPP, MUC without chat rooms and more...
StanzaReceiver is a twin component for StanzaSender but much more powerfull. Hm, so maybe it is not a twin actually...
StanzaSender is a simple and limited component which executes tasks in specified intervals of time. Usually these tasks monitor some resource for data to send as XMPP stanzas. Simple but efficient way to intergrate Jabber server with any other software like web forums, software development management or something different which requires instant notofications about events.
StanzaReceiver on the other hand is much more complex and powerfull component. It is event driven instead of time driven. Events are generated by received XMPP packets.
The basic idea is to distribute messages to subscribed users.
The idea is not new but in IM world it opens quite new possibilities...
- You can use it as a newsletter over XMPP to distribute occasional information to interested group of users.
- You can use it as a mailing list over XMPP which in effect is something like MUC without chat rooms. This is very usefull in many cases. You don't need to have opened many chat rooms to take part in discussions with different groups of users.
- Let's say you have a support forum where users can ask questions and help desk team who can respond for questions. Help desk members can be online and available or can be off line and not available.
StanzaReceivercan notify only those help desk members who are online. Using more advanced task implementation they can not only receive notifications about new posts but they can also respond directly to the Web forum from XMPP client. - If you have short news section on your site and you have a team who can post messages to this section through
StanzaReceiverthey can not only do it directly from their XMPP client but also all other team members are notified about new posts instanly. - For sites and service building community groups this feature is invaluable. Users can easily create own discussion groups based on subscription tasks. They can manage tasks, subscribers, moderate subscriptions and much more. All posts can be archived and viewed online on web site.
Possibilities are endless and most of features mentioned above are already implemented and available in the last Tigase version. For average user it is very simple to use as the system uses just basics of XMPP protocol - <presence> stanzas for subscribtions and status notification and <message> for exchanging information. Nothing more!
Well, <presence> and <message> only are needed for users who just want to use this functionality. I mean subscribe to forum monitor or discussion group. For those who want to create new subscription tasks or manage existing tasks, approve moderations and so on a bit more functionality in client is required. As usually in Tigase server you need a client with good service-discovery and ad-hoc commands support.
You can either install Tigase on your own for tests or you can try all new stuff on the server installed at tigase.org address. Just make sure you create account for yourself on Tigase Web site. You can either subscribe to a number of existing tasks or create new subscription tasks for your tests.
If your client doesn't fully support service discovery it might be difficult to find out what subscription tasks are available. Here is a list of active subscription on tigase.org server so you can simply add some of them as a new contact to your roster and start tests:
- test@srecv.tigase.org - subscription for all kinds of tests, add it to your roster, post messages or wait until someone else posts a message.
- development-news@srecv.tigase.org - I will occasionally send send a message for all subscribes about news related to Tigase development. These news will not be published anywhere else. You will be able to respond directly to me and discuss the topic.
- forum-8@srecv.tigase.org - FAQ forum monitor. All new topics or comments published on this forum will be automatically forwarded to all subscribers.
- forum-2@srecv.tigase.org - Tigase admin support forum monitor. All new topics or comments published on this forum will be automatically forwarded to all subscribers.
- forum-3@srecv.tigase.org - Tigase devel forum monitor. All new topics or comments published on this forum will be automatically forwarded to all subscribers.
- forum-4@srecv.tigase.org - Tigase site forum monitor. All new topics or comments published on this forum will be automatically forwarded to all subscribers.
- forum-1@srecv.tigase.org - Tigase user support forum monitor. All new topics or comments published on this forum will be automatically forwarded to all subscribers.
Trackback URL for this post:
- kobit's blog
- Add new comment
- 4483 reads
To be honest, I think StanzaReceiver can be extended later on with support for full PubSub.
The skeleton which is now implemented and works well for simple <presence>, <message> can be a good starting point and base for future development.
Whoah... Ok.. so. Basically. PubSub was first published in 2002, which was, ergh, not now. Personally I would prefer anyone which comes out with a 'use pubsub in real situations' protocol, and implemented platform elements. Basically you just invented an RSS-ircbot for MUC I think (although without MUC), but I understand your intentions - which were most possibly the intentions why pubsub was built, but with another (a protocol designer's) viewpoint. Still I think if every major client would implement a general PubSubStanzaReceiver (for pubsub or a well-defined sub-protocol like personal eventing), your work was definitely useful, even if it wouldn't be the original format and place where those things would be built - which isn't the main goal in such situations anyway I think.
So: Idea for a generic receiver isn't bad, still I think it's a client, or clientlib -side problem that needs to be solved (even if it wasn't for 5 years).
I say this because I still see pubsub a much more flexible protocol for publish-subscribe situations than anything that could be easily handled.
But the other answer could be - and there's a possibility for it unfortunately - that pubsub is a wrong path, because, for example, it makes client implementations more complex.
but there is significant advantage of using my solution over PubSub.
For PubSub you need special protocol extension implemented in client. StanzaReceiver component is based on XMPP only (except management part) so there is no need for any special extensions on client side. Any Jabber client can benefit from it already...
Just presence and message.
you should check xep 60 :-)