It isn’t part of the item that is published. The only way to get it would be to make the users identity part of the actual payload. There is no getFrom() or getReplyTo() since you are communicating with the pubsub node, not another user.
This is typical of most pubsub type systems, as a common feature is to disconnect the consumers from the producers.
Thank you very much for your answer. It’s what I expected, just wanted to double check.
What i’m actualy proofing is using xmpp for cluster management. There are many usecases where one would like to invoke same ‘admin’ operation across whole cluster, like setting log level to debug for exemple, reset cache, etc etc. I find lightweight xmpp pubsub model very suitable for such usecases. Most of those operations ‘fire and forger’ style (dont’t return anything), but there are edge usecases where client that published requests expects some sort of result from subscribers (like collect stats data,etc…).
How would this feature be best imlepented using smack? I was thinking of something like : client that sends publishes request creates ‘temp’ node and publishes the name of the node as part of request. Upon the receipt of request subsciber executes operation and publishes result to the node whose name he received in request. The client that published the request knows how many subscribers there are for the are and how many response messages to expect. Are there any patterns for such usecases using xmpp pubsub?
Sounds doable and is not that uncommon in the JMS realm where you can actually include a replyTo destination with the original message that was posted.
if I add leaf.subscribe(), getSubscriptions() returns only 1 subscription belonging to current user ( the one that was just created). Subscriptions from other users are still invisible. I’m using openfire 3.7.0.
I never finished that part of the spec myself since I didn’t need it at the time when I wrote the API and simply didn’t have the time to do it all. As a whole,that part of the spec requires a little more than just a simple request to get all subscribers, since it also needs to handle requests to subscribe to the node as well.
On the other hand, if you simply need to get the all of the current subscribers, you can simply create the packet and send it. You can use the SyncPacketSend.getReply() to easily make a synchronous request.