Responses inline...thanks
> > > > OK, I guess I didn't understand what you did after all. > > > > I'm not sure why we are looking at the client side and the reference > > binding invoker? Is there even > > a chain we care about on the client side? Doesn't the chain consist > > of a path from client->binding? > > There is an invocation chain for the client --> reference binding. If the > reference binding allows pass-by-reference, then we don't have to copy the > data on the client side. There might be some reference binding types (for > example, some in-memory transport) that will expose the data by reference. I wonder if our disconnect here is that you view this allowsPBR flag as potentially having some other application whereas I'm viewing it in a less-general manner in which all it says is: "I know this chain doesn't need a PBVI copy". Given my view I don't see it's relevance. > > So I could see some service binding impls, knowing that a copy was > > done by the binding, turning off the PBVInterceptor. > > I was suggesting that the service binding might not know this > > statically, but might know dynamically that the PBV copy does or > > doesn't need to be done. I wasn't thinking of using the Message, or > > anything Tuscany-related necessarily, to make this > > determination. > > So you're looking for Message to determine if the flag should be true or > false, right? If you're asking do I want to look at the Message from the service binding provider, in order to determine whether I want to do the PBVI.copy or not on the chain from the binding to the impl, then my answer is "no". Since I'm writing a service listener I'm not counting on having a Tuscany Message and so wasn't trying to solve the problem of how I'd know. If, instead, you're asking if I want to be able to use the Message to carry the decision that I want the service binding provider to make of whether or not to do the copy, then I'm not sure. I thought the smallest change on top of what you already started would be to add a setting to the chain itself. But, like my first comment shows... maybe I didn't catch the scope of your intent. Scott --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
