sstrigler / JSJaC

JavaScript Jabber Client Library
Other
295 stars 86 forks source link

JSJaCIQ.reply cloning the request #55

Open gavllew opened 11 years ago

gavllew commented 11 years ago

I'm not sure if this is strictly incorrect behaviour, but thought I would bring this up as a discussion point. Are there any cases where you want the contents of the request to be duplicated in the response? I've only used iq stanzas for roster operations so far, but all that seems to be needed there is an empty iq with type='result'.

Wouldn't it be better to start with an empty iq, and just set the 'to', 'type' and 'id' attributes based on the request?

Looks like the same logic may also apply to JSJaCPacket.errorReply().

sstrigler commented 11 years ago

Hmmm. Probably you're right, but I'm pretty sure I had sth in mind when I wrote this function (as by that time I needed it at some of my projects). Regarding errorReply the payload is definitely needed as it is common and probably good practice to send back the original request payload for easier debugging and reference.

gavllew commented 11 years ago

OK, I agree with the error replies - RFC 6120 section 8.3.1. specifies that implementations MAY include the original XML, and this makes sense.

As for normal replies, maybe provide a parameter, or a pair of helper functions - one that prepares an empty reply, and another that prepares a cloned reply.