Vivek Pandey wrote:
> Kohsuke Kawaguchi wrote:
>
>> Paul Sandoz wrote:
>>
>>> But it currently does not work well for an Encoder. It is not
>>> possible to tell the EncoderFacade that it should encode using FI
>>> because it is a run time decision based on a previous response.
>>
>>
>> I think EncoderFacade should be figuring that out by itself, based on
>> the packet. I don't want the caller of Encoder to start worry about
>> which encoder to use or anything like that.
>>
>> Encoder gets to see a packet, so it should use that information (like
>> how the FI content negotiation happened, etc) to determine which
>> encoder to use.
>>
>> So I think EncoderFacade can still work.
>>
> +1
>
IMHO this just adds an unecessary level of indirection for the support
of content negotiation.
>> (But we might want to change getStaticContetnType to take a Packet.)
>>
> This will be good. Can we also make getStaticContentType() and decode()
> to return Iterable<String> or String[] with list of transport headers.
> This would ensure any http header that a specific decoder wants to add
> to a given transport.
>
> For example SOAPAction http header will be needs for SOAP 1.1 messages,
> whereas for SOAP 1.2 the SOAPAction appears as a parameter 'action' on
> the content-Type. Since a decoder is aware of what SOAPVersion its
> dealing with and would also know how this should be represented on the
> wire - as a transport header or as part of Content-Type.
>
But a decoder should not know what the transport is, it is mixing (HTTP)
transport semantics with decoding/encoding, which i think the facades
do to some degree (and also encourage in terms of design).
I think it would be clearer if Decoder/Encoder operated on Message
instead of Packet.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109