Hi Vivek,
I noticed that there is now a DecoderFacade class that checks if the
content type is multipart or a direct stream message, and the
HttpTransportPipe takes a Decoder as a constructor that is generated
from the binding.
Given FastInfoset there are three different formats that could
potentially be received dynamically by the client/server HTTP transport
pipe. Also the decoder facade (what content types it supports) can be
specific to the transport.
Rather than a facade should we be using a DecoderFactory that returns a
Decoder for a given content type? There can be DecoderFactory instance
per pipe (and it could cache Decoder instances appropriately).
This also means it is possible to clearly separate XML decoding and FI
decoding instances. Even though the StAX API is used for the most part i
think this is useful for initiation and may potentially be useful for
future optimization (e.g. SOAP header blocks could be processed in a
different manner to create the stream buffer).
The same thing would also apply to an Encoder.
FI can be turned on by the HTTP client transport pipe depending on what
it previously recieves in terms of transport headers, plus there would
also be logic to disable MTOM when FI is turned. This logic seems best
placed in the pipe rather than in an Encoder facade because it is very
transport specific. Other transports may have different logic to
negotiate content.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109