Judson Valeski wrote:
> Doug Turner wrote:
>
>> I proposed three changes which would address bidirectional IO on a channel. I
>> was under the impression you agreed that this approach was the best...?
>
>
> Your impression is correct. I completey support this solution for bidirectional
> asyncronous IO on a channel. My only objection is to the design detail (which will
> have semantic ramifications) of hanging the content-type off of the nsIStreamInfo.
> You're putting a 1-to-1 relationship on the content-type to request. Rick and I are
> arguing that there's a 1-to-1 relationship between content type and channel (not
> request which you can have multiple of per channel).
>
> nsIChannel(http://www.foo.com/) is always going to have just one content type, never
> two.
>
> Please illustrate under what circumbstances a nsIChannel implementation (transport
> layer, or protocol) would have a content type that would differ from one
> asyncRead|Write() to the next (bi directional or not). If you can point that case
> out, then indeed, content-type info would have to hang off of the request, I just
> don't see that case happening. And, if we do have that need, I'd argue the
> nsIChannel should not longer be the logical connection and that URI's should be per
> request as well. My point is that there's a 1-to-1 mapping between content type and
> URI (currently a channel is a logical connection extension of a URI), and hanging
> the content type off of the request breaks that model.
Consider the implementation of a reusable server connection for protocol
foo, which is a nsIChannel. Various consumers of the server connection
may wish to issue requests and wait for a response. While issueing a
request, the server connection may be in the middle of processing a
response for a previously issued request. In this case, the
content-type of the data being read could very well differ from the
content-type of the data being written. Clearly the content-type of the
channel is not well defined in this case.
So, the question then becomes: do we want to support such a design? I
say yes... especially since we can.
Moreover, there is no reason to force the assumption that the
content-type of a URI will never change. Consider a HTTP server
response that should not be cached. The URL could be
http://www.foo.com/bar. First, it could return XML, and then 5 seconds
later, it could return index.html. Until we have the headers from the
server, there is no way to know, so why lock ourselves into the
assumption that the content-type for a particular URL is static?
Consumers of nsIChannel should understand that without a successful
request, there is no way of knowing the content-type for a particular
URI. The best you can do (without a successful request) is to guess the
content-type using the MIME service.
>
> Again, I agree that these changes need to land in order to get bi-directional io
> going, but I think the content-type is hanging off of the wrong object; the request.
> If it hangs off of the channel life is good.
>
>> this bug has quickly evolved into what I am trying to do:
>>
>> http://bugzilla.mozilla.org/show_bug.cgi?id=65272
>
>
> This bug is about getting bi-directional io going. I believe that's perfectly doable
> w/ out changing the content-type parent.
>
> Jud
>
>
>
