Paul Sandoz wrote:
> Kohsuke Kawaguchi wrote:
>
>>
>> The content negotiation is really more of a property of the entire
>> pipeline, and not a property of a packet. So I think the proper
>> solution is to eliminate the content negotiation property from
>> Packet, and create a mechanism where a change to the pipeline
>> (through request context) could be directly sent to the responsible
>> pipes and codecs.
>>
>> That would allow the FI codec to use the correct content negotiation
>> propery without having the security code worry about FI, which just
>> seems wrong.
>>
>
> How would the conneg property on the client pipe line get propagated
> to the secure conversation pipe line?
>
> Would it occur like the following:
>
> clientPipeLine.propagateProperties(scPipeLine);
One clarification here: the secure conversation has no seperate
pipelines but reusing the client pipeline.
Thanks!
Jiandong
>
>
>
>> Besides, if transport/codec specific details need to be captured on
>> Packet, that sounds like an abstraction breakage.
>>
>
> Seems like the endpointAddress, soapAction and the acceptableMimeTypes
> properties are different because they are meta data associated with
> the message, even if they are transport/codec specific. Where as the
> conneg property is related to client pipe line
> transport/encoding/decoding behaviour.
>
>
>> This change would also allow some computation to be done when the
>> property is set, to digest the value to the form more suitable for
>> efficient processing, as opposed to wait until the last minute to do
>> so (and end up doing so repeatedly.)
>>
>
> At least for the conneg property there is very little overhead (unless
> the property bag falls back to the slow method?).
>
>
>> I think distributed property set is kinda close to what we need to do
>> this.
>>
>
> Are there any other properties? I am just wondering what the cost of
> implemeting this is.
>
> Paul.
>
>> Paul Sandoz wrote:
>>
>>> Hi,
>>>
>>> As i understand it the secure conversation pipe creates a new Packet
>>> for its pipe line from the Packet of the client request. Are there
>>> any other cases where this occurs?
>>>
>>> In the general case, should we propagate the content negotiation
>>> property? i.e.
>>>
>>> private Packet(Packet that) {
>>> that.copySatelliteInto(this);
>>> this.invocationProperties = that.invocationProperties;
>>> this.handlerScopePropertyNames =
>>> that.handlerScopePropertyNames;
>>> this.contentNegotiation = that.contentNegotiation;
>>> // copy other properties that need to be copied. is there any?
>>> }
>>>
>>> So in the case of secure conversation if the client enabled Fast
>>> Infoset then that would also get propagated to the secure
>>> conversation client.
>>>
>>> Given that the 'pessimistic' property will only result in FI being
>>> enabled iff the service is FI-enabled the propagation of this
>>> property will not affect the interoperablity with non-FI-enabled
>>> secure conversation services.
>>>
>>> Paul.
>>>
>>
>>
>