Paul Sandoz wrote:
> Hi,
>
> I am implementing support for FI content negotiation and would like to
> know what is the best way is to propagate the conneg property on the
> request context to the packet.
I think this is touching a deep issue, of how to allow applications to
configure pipes through a proxy. This is really a very generic problem
that will happen to any non-trivial pipe.
For example, HTTP transport might want to allow users to set a proxy
authentication information, security might want to let people change the
keystore (I'm just making this one up), and so on.
These configurations aren't really a "packet" property. There really is
no need for those values to be passed around between pipes. It only
needs to be delivered to a particular pipe that it's intended to.
Besides, attaching them to Packet is not good for performance, because:
- Stub has to always copy values from request context to Packet
- Pipes have to check for them all the time
It seems to me that a better approach is to somehow allow pipes to
expose properties to RequestContext directly, in such a way that the act
of setting it would immediately call the corresponding method on the
corresponding pipe (as opposed to values set to Packet, to be picked up
by a pipe)
A downside is that it interacts with asynchronous invocations (changing
a property while asynchronous invocation is in progress may affect that
invocation, while ideally it shouldn't.) I know that the spec-defined
properties must observe this carefully, but I think we can do this for
many proprietary properties, such as FI content negotiation.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com