[jdev] nonblocking RPCCall() in Net::Jabber, can it work?

[Ryan Eatmon]

Scott Bolte wrote:
> 	Thanks for the information Ryan.
> 
> 	I am using RPCCall with mode => 'nonblock'. It has to be
> 	non-blocking since the remote 'user' may be offline when I
> 	make the call.
> 
> 	Like I said, I'm new to jabber, but it looks like SendWithID
> 	does register the ID and packet table.

Ok... I had a brain fart. =)

Yes.  SendWithID (nonblock) does call RegisterID.  The mode I was 
thinking of is passthru, that just adds the id and returns it.

 >       The code path from
> 	RPCCall will include the following line:
> 
> 		$self->RegisterID($object->GetTag(),$id);
> 
> 	I haven't tested it, but I'll speculate RPCCall should
> 	return [$iq->GetTag(), $id] instead of ($id). That would
> 	allow CheckID to be used minutes/hours/days later. The
> 	other solution is to drop the reference to CheckID from
> 	the Modes section of the Net::Jabber::Protocol man page
> 	and point people to XPath for both nonblock and passthru.

No...  you're right.  It might be better to return both things.  For now 
though, you can just call CheckID with ("iq",$id).


> 	I'll add XPath callbacks to my list of things to learn.
> 
> 	In any case, I think I see trouble ahead. The generated id
> 	does not seem unique over time. Therefore replies that comes
> 	to a client's successor, even a successor that shares the
> 	same JID, may be ambiguous. Is that correct?

Unique over time?  I'm not sure I understand.  It is unique over time if 
you stay connected.  But if you disconnect and reconnect then yes, the 
id counter is reset to 0.

What exactly are you trying to write that requires such a lengthy 
processing time?  RPC is meant to be be instantanious response, not 
hours/days/weeks/etc...


> 	Btw, it was the persistence of messages that I did not
> 	realize jabber had until last week. (I know, it's an obvious
> 	requirement in light of offline messaging, but I know more
> 	now.) Persistence is the reason I'm switching over to Jabber.
> 	But I now realize there is a critical question I need to
> 	ask...  will a session manager (e.g. jabberd 2) store both
> 	IQ and Messages packets or just Messages?

<iq/>s are not stored offline.  Only <message/>s.

> 		Scott
> 
> 
> Ryan Eatmon wrote:
> 
>>First, are you using the new mode=>'nonblock' argument to the RPCCall 
>>function?  This causes RPCCall (and several other functions) to return 
>>the id that the packet was sent with.
>>
>>In this case it just calls SendWithID which does NOT register the id and 
>>packet tag in the id table.  So CheckID() will not return anything 
>>because it was never registered.
>>
>>The idea behind this method of operations is that you would register an 
>>XPath callback on that id that would call a function of your devising 
>>to handle just the return packet call.
>>
>>$client->SetXPathCallBacks("/iq[\@id='$id']"=>&yourFunction);
>>
>>yourFunction would then call RPCParse to get back a data structure for 
>>the return value.
>>
>>This *should* be as close to nonblocking as we can get.  Your code will 
>>return to the Process() loop and let you do whatever while waiting for 
>>the return.  Since you know what was going on at the time the RPC call 
>>was sent, you can tie that state information in a hash with the id 
>>returned from RPCCall as the key.  Then you can look up the state 
>>information in yourFunction.
>>
>>One caveat.  If this is a long running program.  Make sure you 
>>unregister the XPath callback in your function since the id will never 
>>be recycled.
>>
>>$client->SetXPathCallBacks("/iq[\@id='$id']"=>undef);
>>
>>Hope this helps.
>>
>>
>>Scott Bolte wrote:
>>
>>>	As far as I can tell, it is not possible to use CheckID() to
>>>	retrieve the answer to a non-blocking RPCCall() call.
>>>
>>>	CheckID() requires an object tag and an id. Unfortunately,
>>>	RPCCall() returns just an id. The iq object it creates goes out
>>>	of scope, taking the tag with it, when RPCCall() returns.
>>>
>>>	I've only been using Jabber for two days so I suspect I'm
>>>	missing something. Is there any way to do non-blocking RPC and
>>>	later retrieve the answer packet?
>>>
>>>		Scott
>>>
>>>	P.S. I am using version 1.29 of Net::Jabber.
>>
>>-- 
>>Ryan Eatmon
>>reatmon at jabber.org
>>
>>_______________________________________________
>>jdev mailing list
>>jdev at jabber.org
>>https://jabberstudio.org/mailman/listinfo/jdev
> 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> https://jabberstudio.org/mailman/listinfo/jdev

-- 
Ryan Eatmon
reatmon at jabber.org