Pedro Melo wrote:
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?
You're not checking the disco NodeID, you're checking the disco#info
against the caps hash you have on file for that user. Or so it seems to me.
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;
Agreed, business as usual.
* 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.
I think you'd ping someone else in your roster if a problem like that
persists. I'm not sure what you mean by "represent the client
capabilities until you get a new caps hash" because hash doesn't match
the disco#info.
Peter
