Judson Valeski wrote:
> Doug's got it :-). Rick Potts and I just got off the phone and he
> refreshed my memory a bit.
>
> 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)).
Right, this makes sense. But, what if "the data trying to
be reached had [NOT] been reached?"
>
> 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.
So you are suggesting that a particular set of nsresult
values would indicate failure _without_ the need to clean
up their init'd stuff? And, that another set of nsresult
values would indicate failure _with_ the need to clean up
their init'd stuff? This sounds complicated.
Perhaps it would be just simpler for the listener to keep
track of whether or not OnStartRequest was called. This
need not be an explicit variable... the listener could
just check to see if something was init'd or not.
>
> 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).
The problem, as I understand it, is that if we allow OnStop
acting alone, we are going to get many crashes... as the
code in the various OnStop's tend to assume OnStart has been
called. But, these could be considered bugs and then fixed.
>
> 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?
HTTP does this too.
Darin
