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. 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.
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?
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?
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("/[EMAIL PROTECTED]'$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("/[EMAIL PROTECTED]'$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
> [EMAIL PROTECTED]
>
> _______________________________________________
> jdev mailing list
> [EMAIL PROTECTED]
> https://jabberstudio.org/mailman/listinfo/jdev
_______________________________________________
jdev mailing list
[EMAIL PROTECTED]
https://jabberstudio.org/mailman/listinfo/jdev
