Judson Valeski wrote:
> 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 am not finished with the changes, but I expect at least a week of regression
testing on my branch. I hope to involve Netscape's QA as well as some mozilla
qa folks.
> 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.
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...?
Without following through on these changes will leave nsIChannel's effectively
useless for bidirection io. Look at Imap and HTTP, both can be simplified if we
could do both AsyncRead and AsyncWrite at the same 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
sarcasm yes. Ingore please.
> 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.
The branch is building. I need to make some adjustment and remove some of the
hacks that I found. I also have to wait until Darin land his AsyncWrite changes
on my branch. At that point, when I am more confortable about how stable my
branch is, I will indeed get you and the rest of the world involve in testing
and reviewing. Also note that anyone that want to get a head start can either
pull the branch at look at my changes (which you have done ty), or contact me
about trouble areas (like dmose, he asked me to take a look at this LDAP stuff).
> 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)?
More of a practical scenario. You really can't do async bidirection IO on a
socket.
this bug has quickly evolved into what I am trying to do:
http://bugzilla.mozilla.org/show_bug.cgi?id=65272
