See my comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Scott Kurz" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, February 20, 2008 10:56 AM
Subject: Re: Bypassing unnecessary transforms by Tuscany databinding
framework
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 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.
There is also an invocation chain for the service binding --> impl. If the
service listener receives data from a transport that pass data by value
(such WS or RMI), there is no need to copy data on the service side.
(Does the chain ever span a binding? maybe in the default binding case?)
Not really, in the default SCA binding case, the SCA reference binding
invoker is responsible to connect to the service-sode invocation chain.
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?
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
