Hi,
When we discussed F2F how to integrate FI into encoder/decoder facade we
concluded that the best way to do this using the current transport
framework is to merge the Encoder/Decoder concept into a Codec since FI
content negotiation requires that state between successive
requests/responses be maintained (although it may be possible to avoid
this merge, see below).
When FI is enabled the following stages will occur:
1) The client sends the first request in XML, with an Accept HTTP header
field saying that it accepts FI.
2) The server receives the XML request message
2.1) If the server supports FI and FI is an acceptable response, the
server will reply with a response in FI
2.2) Otherwise the server will reply with a response in XML.
3) The client receives the response message
3.1) If the response is in FI then the next any subsequent future
requests to the server will be sent using FI.
3.2) Otherwise the next request will be sent using XML.
In other words...
The client requires that state be maintained over multiple
inbound/outbound message exchanges:
- if the previous inbound message was in XML then the current outbound
message will be in XML.
- if the previous inbound message was in FI then the current outbound
message will be in FI.
The server requires that state be maintained over the inbound/outbound
message exchange:
- if the inbound message is XML and an FI outbound message not
acceptable then the outbound message will be in XML.
- If the inbound message is XML and an FI outbound message is
acceptable then the outbound message will be in FI.
- If the inbound message is FI then the then the outbound message will
be in FI.
I am not sure it will be possible to utilize the same Codec facade for
client and server because of the different requirements, however that
should come out in the wash whether it is possible or not.
Currently i think it will be necessary to have the following fields on
Packet (unless there is a better place to put them, but are still
efficiently set/getable through Packet):
- content negotiation property; and
- HTTP accept field.
The second is very specific to HTTP but i think that could be considered
the canonical representation.
We may be able to avoid the Encoder/Decoder merging into Codec if there
is another property on packet that represents the content type of the
last inbound message in the message exchange.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109