I had been thinking about doing this for a while. In the last Oxford Drupal User Group meeting, the BEAN (Block Entities Aren’t Nodes) module was mentioned. This allows a module to declare types of blocks which a user can then use as a content type. Instead of having to create various forms, it hooks into the content section. The BEAN project page has some excellent tutorials as to how to use it which I’m not going to reproduce here. I decided to use the module and put in a field for a description. Using BEAN gave me a way of creating an easy to use block which could be re-purposed if necessary and to which a content creator could add a description if required.
Back from the digression….
I have an interest in messaging and there already exists a STOMP module which provides an integration into ActiveMQ using STOMP. I haven’t fully tried it yet but I wanted to provide a way of a message system updating a screen remotely with feeds without polling a back end.
One way of doing this is to set up a page which can be called in a similar fashion to the way that autocomplete works: a remote page which wraps around the STOMP library and present the message body to the screen and the calling page works out how to display. I wrote something like this several months ago but decided that it was too scrappy to be released.
My intention was to use a similar mechanism so that back end systems could send updates to users. For example if a system had an urgent update for users, this could be pushed out immediately without a page needing to spend a while waiting for an update. Quite simply, this is all that the module does.
When the page is loaded, any messages are then printed out to the screen very quickly.
It is an extremely simple mechanism which satisfies my original curiosity in writing something where updates can be published.
Where I would like to go is to develop this from the simple print to screen to being a list of messages which are printed out. It also needs testing with other STOMP and Web Sockets supporting messaging system, such as RabbitMQ.
What it shows is that message queueing can also be used to send updates out rather than purely being an arcane piece of middleware used for integration. Real time updating can be done from these useful tools rather than having to use Node.JS (and nothing against Node, I wanted to do some thing slightly different).
I am rather glad that I wrote the module and, more importantly, published it. It is simple, perhaps overly so and there is room for improvement which can always come. Perhaps this is from the fact that this module was developed from curiosity rather than a direct need.