Doug Turner wrote:
> >> No, that is wrong. Different imaginable implementation of nsIChannel
> >> could return different contents based on read/write positioning.
> >
> > 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.
>
> I have already made all the changes on my branch and either it was a
> trival change or the code was doing the wrong thing in the first place
> (eg. depending on the content type on the channel before any request was
> made)
I'm sure the api changes were indeed trivial (just lots of files). Semantics
have changed as a result of your changes though, and those places where
"code was doing the wrong thing in the first place" will haunt you if you
change them :-). What kind of regression testing have you done? Did you try
those cases I suggested in a previous posting? One thing I didn't mention as
a place to test was Mac. The mac's nsIMIMEService implementation plays w/
IConfig and there are some semantic differences between mac and windows as a
result. You'll need to test the same cases on the mac as well.
I don't think I mentioned i18n tests either. Try opening a japanese
character html (and plain text) file from disk, lacking an extension
(lacking extensions forces the UnknownDecoder to scan bytes).
I'm don't mean to 2nd guess your work, but this is a significant semantic
change which we've tried to make many times. Reprocussions have forced us to
turn back each time.
> > You won't get this far without months of effort. We've tried before (3
> > times).
>
> I have not tried. :-)
This stmt seems to contradict what you said above about having the changes
on your branch. Is that smiley for sarcasm, or am I missing something? If
it's sarcasm, and you have indeed implemented these changes, let's sit down
and go through what needs to be tested before landing these. I'd like to
review the changes before landing as well.
You didn't answer my question about motive for these changes. Are they for
design's sake, or are you confronting a practical scenario in which you need
each request to have a different content type (your use of this in FTP will
always return the same content type for all requests on the command channel
(which is the channel which raised the issue of overlapping i/o to begin
with)?
Jud
