hi all, a quick question here: are there any plans to implement XEP-0184 Message Receipts as defined here: http://www.xmpp.org/extensions/xep-0184.html.
thanks!
1 Like
is this the right forum to ask this question?
is any other place better suited for my questions?
please advise.
thank you.
is this the right forum to ask this question?
Hm, this forum is for Openfire server. XEP-0184 seems to be independent form the server? Server just needs to relay messages.
=> This must be implemented on client side? I think current versions of Miranda do support this already.
sorry for getting back to this thread so late…
coolcat,answering a question with another question? this is a very good technique in school and when you master the answer already… obviously not in this case though 
xep-0184 is covering both the server and the client: chapters like “determining support”, “negociation” should clearly tell you that this is not a client only specification.
Coolcat is correct. The XEP-184 is mainly for clients. A more correct answer would be between XMPP entities (e.g. clients, components, etc.).
Regards,
– Gato
chapters like “determining support”, “negociation” should clearly tell you that this is not a client only specification.
No, the server needs only to relay packets between the clients. The server does not need to understand what this is.
so how this aplies to pub-sub messaging? after i publish i don’t want to get back 1000 receipts (if there are 1000 subscribers) i want only one receipt from the server to tell me it got the message/item and it was published successfuly.
I don’t see how XEP-184 relates to pubsub. XEP-184 is about a client requesting another client to send a confirmation that a message (sent by the client) was received. In pubsub someone will publish something to a node and the pubsub service will send messages to the subscribers. The pubsub service (by default and the current implementation) will not ask clients to confirm that those messages/notifications were received.
– Gato
that’s the whole point of xep-0184, is a mechanism (from a series of them) that will help one to guarantee delivery. pub-sub or not, as long as a message/item has to be delivered receipts comes in handy when you are on your way to guarantee delivery (of couse, other conditions have to be met too).
xep-0184 is very well valid for pub-sub also, it is exactly how u say, a client requesting another client, only that one client is the pub-sub service
it can be used for the publisher-service communicatio; this way a publisher will re-publish an item it didn’t get receipt from the server it was published; and it can also be used for the service-subscriber communication; the service will keep sending a published item/notification as lons as it didn’t get a receipt from the subscribers they got it.
i don’t see why this aplicability of xep-0184 is not correct? i asked Peter Saint-Andre (https://stpeter.im) and he seems to agree with my point, see http://mail.jabber.org/pipermail/standards/2008-October/020120.html.
How about if the message is cached by the server and deliverd later when the reciver comes online?
Is this to be handled by the server?
From a sender point of view ther is no need to resend the message in this case.
After checking more on XEP-0079: Advanced Message Processing it looks like that specification is what I am looking for and in some case a combination with XEP-0184 for knowing handeling by the receipt client…