Darin Fisher wrote:
> 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.
>
I don't understand this example... Are you saying that given the URI 'foo://bar' if
the
consumer does two consecutive reads, it will get back data with *different*
content-types? I don't see how this is useful?
It sounds sort of like connecting to the 'quote of the day' server (except for
different
content-types :-)
I'm sure that we could invent some protocol which could do useful work using this
model,
but I don't see that any of the protocols which we currently support (or would want to
support) require this feature...
As far as I can see, the real question is whether a single URI can contain data of
multiple content-types? My assumption is that there *is* a one-to-one mapping from a
URI
to a single content-type.
In your example, if the multiple consumers are issuing requests of the same nsIChannel,
then they *must* all be receiving data of the same content-type... So, as soon as the
content-type is discovered it will be the same for all requests made to that channel.
The only counter-example that I can think of is the 'multipart/x-mixed-replace' case,
where each piece of the stream can have a different content-type... But even in this
case, a single request could span multiple content-types (ie. you could read more than
one
part of the multipart response...).
So, even in this situation, associating the content-type with the request, rather than
the
channel, does not solve a problem...
>
> 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?
>
As far as I can see, by relocating the content-type you just 'move' the problem from
nsIChannel to nsIRequest. In the first case, if you cache a given channel and assume
its
content-type remains constant after the connection has close it might be stale.
The same is true in the second case, if you cache a given nsIRequest and assume its
content-type remains constant after the connection has closed...
In both cases, the state associated with a channel (or request) represents a snap-shot
in
time... The only way to "protect" consumers from this would be to invalidate all of
the
state attributes as soon as the connection is closed...
I would argue that a better solution would allow consumers to determine whether a
connection was still alive (and therefore have valid state...)
>
> 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.
>
I totally agree that for some protocols, until a connection has been established the
content-type is not known... However, I don't see that moving the content-type into
*every* request makes things better...
In the current model, it is assumed that as soon as a consumer receives an
OnStartRequest(...) the content-type is available from the channel... The same would
be
true if the content-type were accessed via nsIRequest.
The difference is that moving the content-type into nsIRequest would still require each
channel implementation to cache the content-type... And would require alot of work
dealing with that situations where the content-type is accessed *after* a request has
completed...
In the end, it looks like alot of work that doesn't really solve any problems...
-- rick
>
> >
> > 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
> >
> >
> >
