It's not worth bothering to tweak reply LLSD or attempt to send it if the
incoming request has no replyKey, in effect not requesting a reply. This
supports LLEventAPI operations for which the caller might or might not care
about a reply, invoked using either send() (fire and forget) or request()
(send request, wait for response). This logic should be central, instead of
having to perform that test in every caller that cares.
The major alternative would have been to treat missing replyKey as an error
(whether LL_ERRS or exception). But since there's already a mechanism by which
an LLEventAPI operation method can stipulate its replyKey as required, at this
level we can let it be optional.
Each LLEventAPI method that generates a reply needs to extract the name of the
reply LLEventPump from the request, typically from a ["reply"] key, copy the
["reqid"] value from request to reply, locate the reply LLEventPump and send
the enriched reply object. Encapsulate in sendReply() function before we
proliferate doing all that by hand too many more times.
Replace LLEventPump's boost::scoped_ptr<LLStandardSignal> with
boost::shared_ptr. Take a local stack copy of that shared_ptr in post()
methods, and invoke the signal through that copy. This guards against scenario
in which LLEventPump gets destroyed during signal invocation. (See Jira for
details.) Re-enable Mani's test case that used to crash.
Introduce ll_template_cast<> to allow a template function to recognize a
parameter of a particular type.
Introduce LLListenerWrapper mechanism to support wrapper objects for
LLEventPump listeners. You instantiate an LLListenerWrapper subclass object
inline in the listen() call (typically with llwrap<>), passing it the real
listener, trusting it to forward the eventual call.
Introduce prototypical LLCoutListener and LLLogListener subclasses for
illustrative and diagnostic purposes. Test that LLLogListener doesn't block
recognizing LLEventTrackable base class bound into wrapped listener.
implement the ["reqid"] convention. This convention dictates that a response
LLSD from each such API should contain a ["reqid"] key whose value echoes the
["reqid"] value, if any, in the request LLSD.
Add LLReqID support to LLAresListener's "rewriteURI" service, LLSDMessage,
LLCapabilityListener and LLXMLRPCListener.
Richard Linden