The "original" semantics of nsIStreamObserver were such that OnStart was called to indicate that the data trying to be reached (the URI) had been reached (the file:// file had successfully ben fopen'd, the http:// host socket had been connected. the definition of "reach" is up to the transport). You'd get an OnStop indicating the transaction was complete (whether for connection failure reasons, data transport failure reasons (timeout)).
So, Darin, if we break the semantics of *always* coupling an OnStart w/ an OnStop, we can use OnStop to do what you're proposing. The consumer would only do setup type stuff in OnStart (w/ out fear of doing it for no good reason), and their OnStop would always check the nsresult passed in to decide whether or not to finish the transaction and clean up their init'd stuff.
We tried to enforce these semantics in the past and were pushed to provide the OnStart/OnStop coupling semantics, but we should probably move back to OnStart on successful "start" followed by OnStop (so OnStop can act alone).
Scott,
Does the docloader propegate OnStart's in failure
cases? If so, do you think it's heavy to change that?
Doug,
Currently FTP fires OnStart's in error cases, we'd
need to change that?
Doug Turner wrote:
What was the reason for this proposed change? is there a bug with more context?The way I see it is that the error handling should be done in the |onStopRequest|. Until then, it is assumed that everything is going okay. Would this be some kind of callback so that you could correct problems?
