We talked about this in our group meeting last week... We should add an accessor to nsIChannel to allow us to set channel argument used in the event sink callbacks. Right now, down deep in the transports, they do something like this: mUserListener->OnStartRequest(this, mUserContext); but if they could do this: mUserListener->OnStartRequest(mUserChannel, mUserContext); it would allow us to avoid a whole layer of nsIStreamListener implementation in the channel implementations. (Look at nsFileChannel for an example.) Note that this change might have be done hand-in-hand with one to change the way load groups are managed since the OnStopRequest often removes the current channel from the load group in addition to passing the OnStopRequest notification upstream.
Enhancement for protocol writers.
Severity: normal → enhancement
Summary: add 'callback channel' to nsIChannel interface → add 'callback channel' attribute to nsIChannel interface
Target Milestone: --- → M20
Open Networking bugs, qa=tever -> qa to me.
QA Contact: tever → benc
to darin, the keeper of nsIChannel
Assignee: warren → darin
Priority: P3 → P5
Target Milestone: --- → Future
this is now pretty much invalid given architectural changes in necko, but the general idea might still be applicable to nsIInputStreamPump, but nearly all of our channels do non-trivial stuff in OnStopRequest... usually releasing owning refs to stuff. therefore, marking INVALID.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → INVALID
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.