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?
I thought it would ONLY be the service side on which we were interested in using the PBVInterceptor.copy or not, on the path from binding->impl. (Does the chain ever span a binding? maybe in the default binding case?) 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. But once I found out I thought it would be nice to dynamically turn off PBV copy on the chain. Scott On Feb 20, 2008 1:22 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: > The reference binding invoker can implement the "allowsPassByReference()" to > return conditionally. Are you looking for the dynamicity at the per > invocation level (i.e., need to check the Message)? > > As I said before, the client (such as the proxy handler or service listener) > of the invocation chain should decide if the PBVInterceptor (should be > refactored into a utility) should be used to copy the data. > > Thanks, > Raymond > > ----- Original Message ----- > From: "Scott Kurz" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Wednesday, February 20, 2008 9:48 AM > Subject: Re: Bypassing unnecessary transforms by Tuscany databinding > framework > > > > > Yes I can envision some useful transforms which wrapper/unwrapper data > > formats without doing copies. > > > > That raises the question of how to turn off PBVInterceptor dynamically. > > > > I guess I hadn't given this enough thought before, since actually I'd > > like to be able to do the same from the binding impl... I'd like to, > > dynamically at invocation time, be able to turn off the > > PBVInterceptor. > > > > It seems like we could use a setter on the chain itself to do this. > > > > Then we still have the question of how to turn off the copy or not for > > particular data transforms. I agree turning it off > > is a good default, but it seems like it should be a possible for a > > particular transform to, even dynamically, decide > > that, as far as it knows anyway, the PBVInterceptor copy may still be > > needed. > > > > What do you think? > > > > Scott > > > > On Feb 19, 2008 10:32 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> > > wrote: > >> Raymond Feng wrote: > >> > That was my intention to return true as the DTInterceptor will make > >> > sure > >> > the data passing is safe. > >> > > >> > >> Is that always a correct assumption? I thought that it could depend on > >> the nature of the transformation. Some transforms would copy or protect > >> the data, some wouldn't... > >> > >> -- > >> Jean-Sebastien > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
