> I'm assuming that the server's BLIP dispatcher could read a property
> on a message to determine which instance the message is directed to
> and then formulate the method call, pass it to the instance, take the
> return value and package that back up and send it back to the
> requesting client as the response to the original request.
Well, the dispatcher can be given rules (predicates), and when a rule
is matched, a particular message will be sent to a particular object.
But it can't do anything nearly as fancy as what you're saying — it
can't pull properties out and use them as parameters in the message
call, or call different objects based on different property values.
You'd have to write that code yourself.
—Jens
> I'm new to programming, so, please excuse me if this is a simple /
> stupid question, but, is it possible to use the dispatcher to invoke a
> method on another object, take the return value from the invoked
> method, and send it back as the response to the original request?
No. The target methods called by the dispatcher are assumed to take
the BLIPRequest object as a parameter, and not return anything. It's
each target method's responsibility to interpret the contents of the
request, do whatever it needs to do, and optionally put response data
into the associated BLIPResponse object and send it.
It's certainly possible to implement something like what you're
talking about, but it would be a fair bit of work to marshal and
unmarshal parameters automatically.
—Jens