William Voorsluys wrote:
Hello,
> Justin, what say you?
I'm against adding redundant information like this into the stanzas.
Maybe William can explain what he means by "filtering" and how this is
difficult?
This is really an implementation issue and is more related to parsing.
Suppose I need both 'sid' and 'seq' to be included in the response.
Without child elements I would use an 'id' like "sid001_10". Since the
values I need are not as an XML structure, I need to create a special
"ID parser" that would break the id into pieces and deliver the values
to the application.
This is needed because we want to create Packet Filters in the Smack
library that only match a specific session id. Messages of the
different sessions are delivered to different Objects (the Packet
Listeners or Packet Collectors). If I don't break the 'id' and get
'sid' to use as the argument input, I have to create one Packet
Collector for each message sent, using the full 'id' as the filter
argument, so that the correct sender will receive the message
acknowledgment.
As I said, this is an implementation issue and we could cope with
using just 'id' for tracking packets, even though it makes the
implementation harder.
Thanks,
William.
For xmpp, iq response (result/error) and requests are to be associated
based on [from, to, id] tuple - nothing else. So expecting or relying on
other additional information will not work across usecases or clients.
And it makes no sense to duplicate this in other forms when it is
possible to make this associated unambiguously.
For example, the response need not contain the namespace element to
which the request was sent to, but can be a bare response (<iq
from="[EMAIL PROTECTED]" id="reqid" type="result" />). I have seen libraries
assuming recommended behavior as though it was MUST and not handling
these cases.
Mridul
