On Jul 1, 2008, at 11:18 PM, Tobias Markmann wrote:
On Tue, Jul 1, 2008 at 11:43 PM, Peter Saint-Andre
<[EMAIL PROTECTED]> wrote:
Tobias Markmann wrote:
Hi,
First of all kostix from tkabber found an invalid example in
XEP-0115 under http://www.xmpp.org/extensions/
xep-0115.html#discover . Example 4 should be:
<iq from='[EMAIL PROTECTED]/orchard' id='disco1'
to='[EMAIL PROTECTED]/balcony' type='result'>
<query xmlns='http://jabber.org/protocol/
disco#info'> node='http://code.google.com/p/
exodus#QgayPKawpkPSDYmwT/WM94uAlu0='>
Currently the query tag is close before node attribute.
Typo fixed.
The next thing is I'm upgrading pidgins caps support and some
question arise from time to time.
Is the node attribute in the query tag required in a disco result
since the XEPs' examples include it but the scheme doesn't tell
anything about it.
I think it is recommended, but if the processing application
doesn't receive it in the disco result it needs to process the
disco anyway.
So if I send a query with node 'http://code.google.com/p/
exodus#QgayPKawpkPSDYmwT/WM94uAlu0=' can i expect the result
includes a node attribute too?
If yes I could easily compare the hash inside the node to the self
generated hash of the query contents and cache it on match.
Yes that seems best. I think we can make it required if that would
be helpful. However, the client should remember it based on the IQ id.
Peter
Okay. How should a client respond if it requests disco for a node
with the caps hash of the previous presence though receives a disco
result with a node url including a different hash?
Did you receive a new presence from that client between the moment
you sent your IQ request and you got the IQ reply? If yes, and if the
hash in said presence is the same as the response, then I would make
it "business as usual". Basically, you accept that the response is
consistent with the current caps hash for that client.
In a general way, I would say:
* if the hash matches the payload of the IQ response, then you can
cache it for future use;
* if the hash does not match the payload; you cannot cache it (as
per spec), but you should use it to represent the client capabilities
until you get a new caps hash.
It this reasonable?
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [EMAIL PROTECTED]
Use XMPP!
