Judson Valeski wrote:Hmm, ok. This rocks my world then. Necko's channel/callback design was born out of the idea that there was one content type per channel, and that a channel ultimately represented a "connection" to a single URI. You're turning that on it's head.Doug Turner wrote:No, that is wrong. Different imaginable implementation of nsIChannel could return different contents based on read/write positioning.Both are attributes that you do not know until you do a read. We have aRegarding moving content-type out to the request. I'm not clear on why it shouldn't be rooted in the nsIChannel either. We have the following structure
hack in http which guesses before any transaction, but this is all
wrong. This hack basically uses the MIMEService and guesses based on the
URI's file extension. I hope to move these kind of guessing outside of
the nsIChannel/nsIRequest.channel (say, http://www.foo.com/bar.html
|
-------------------------------------------
| |
nsIRequest (from an AsyncRead) nsIRequest (from an AsyncWrite)
the content type of the Read or the Write is always going to be the same. I don't see when it will be different; thus, content-type should be rooted off the channel.
I can imagine a case where two reads from different offsets could return different content types.So can I, but I can also take that example (the one in my mind is a flat file cache that pushes all cache content into a single file), and push it up one level to have each channel represent a file within the cache model, rather than the channel representing the whole flat file cache.
I'd rather not change the content-type to channel paradigm unless there's compelling reason to do so. "I can imagine a case where" is a good excersize for initial design, but we can't ignore the current model (which I think would be confused by hanging content-type off of the request).
Ultimately I'm arguing for clean design. You've made it clear you can get back to a request's root if you need to (so you *could* go up to the channel to get the content type), so is your practical motivation for wanting to hang the content type off the request because it reduces a function call to get back to the channel?
They definently would return two different content length.indeed. (byte range requests)
Content type and length is part of the information that you get from a request. Anything before that is a guess. There are too many places in the code right now that do the wrong thing wrt creating channels vs. opening them. Making content information only available after the request is the right thing to do.You won't get this far without months of effort. We've tried before (3 times).
I urge you to checkout some old necko postings on this topic (news:[EMAIL PROTECTED] - "Separating out the notion"...).
So you know where I'm coming from... I couldn't agree more that we need the extra layer (content type negotiation phase) built into necko. But, keep in mind that necko is generally asynchronous, and we wedged that async model into a sync codebase with lots of challenges. Adding the content type negotiation layer interrupts flow, again, and comes w/ it's own set of challenges.
Jud
