Jitendra Kotamraju wrote:
>> Does FI interact with HTTP? Is that because you use Accept (or some
>> other HTTP) header? Does that mean FI can be only used with HTTP?
>> Decoder takes a Packet, which contains transport-specific information
>> in it. Can you get to Accept header from it?
>>
>> I think it would be nice to keep the transport and the encoder separate.
>
>
> I think so. FI's content negotiation is based on HTTP headers and except
> that it doesn't depend on HTTP(The encoding itself doesn't depend on HTTP).
>
The client side depends on the semantics of HTTP agent driven content
negotiation. It is tightly coupled with the HTTP request/response MEP
and conformant the the SOAP HTTP binding.
A client can only send request 'n+1' in FI if the response 'n' was in FI
for a request 'n-1' in XML with an Accept header stating that FI is
supported.
Obviously things would be much simpler if it was statically known
upfront that a service supports FI! which is something i would also like
to support using policies.
>>> If the encoder facade is used how can the transport inform the facade
>>> to encode using the FI encoder?
>>
>>
>>
>> For the above reason I really don't want the transport to choose which
>> encoding it uses.
>
I understand the concern.
My current thinking is that the transport pipe is really a
transport+binding pipe and that the transport should be something a
little simpler and separate. I think this can simplify the design but it
does put more onus on developer of a transport+binding and transport.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109