Judson Valeski wrote:
> 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).
Moving content information on to the read is important for a few reasons. First the
content lengh, if you request a bit range read on a certain channel, I am not sure
exactly what the content length should return. Maybe for http, we still are going to
use what the http response gave us, but I am not completely sure that all
nsIChannel/nsIRequest implementions will honor this. Maybe, some implemention will
want
to set the content length equal to the range of the read. I think that this would be a
valid thing to do and make sense that this attribute be on the request since different
range request would result in different content lengths.
The second reason that the content information should be on the request is less
important but still a concern. Suppose that different bit range resulted in different
content types. Although, I do know know of any standard protocol that requires such an
operation, I would hate to do anything that would prevent this. Keeping the content
information on the request allows for different content types for different reads.
Another reason is that content type information is not valid until the channel is
opened
resulting in a nsIRequest. Any query before the channel has been opened is a guess and
should probably be explict to the user. HTTP is the evil case where it queries about
content type are redirectied to the mime service before the channel is opened. There
are a few usages that create a new channel and then immediately query for the content
information, without ever attempting to open the channe. These usages should be fixed
to use the MIME Service. Moving content information to the request will present a
cleaner usage to developers.
> 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.
>
I am glad that we are on the same page here. ;-)
>
> > 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.
Your right. However, part of the motiviation is to factor out state information from
the channel and put it into the request. I think that we are debating if content type
information is a request attribute or a channel attribute.
