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.
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
