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.
Besides, if transport/codec specific details need to be captured on
Packet, that sounds like an abstraction breakage.
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.)
I think distributed property set is kinda close to what we need to do this.
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.
>
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com