Darin Fisher wrote:
>
> Okay, then we have it. Let's try to allow OnStopRequest's to precede
> OnStartRequest's in the event that an error has occured before the
> channel implementation has called OnStartRequest. It just requires a
> bit more care on the part of the listener implementations, but that
> should in general be a good thing anyways.
close. You'll *never* get an OnStop() then an OnStart(). If there's an
error before OnStart() is called, you'll get a single onstop()
indicating why. If there's an error after onstart() you'll get your
onstop() indicating why as well.
Jud
>
>
> Darin
>
>
>
> Judson Valeski wrote:
>
>> Scott, talk to us about the docloader.
>>
>> Darin Fisher wrote:
>>
>>> 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?"
>>
>>
>>
>> If you resolve the server and connect (or open the file), you get an
>> OnStart(). If you fail from that point forward (read timeout for
>> example) you go straight to OnStop() w/ an error code. If the connect
>> failed, you would not get an onstart, and you'd go straight to onstop.
>>
>>>> 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.
>>
>>
>>
>> No, that's up to the consumer's impl. Here's mine.
>>
>> judsimpl::OnStart() {
>> // the transaction has "started"
>> mMyPrivateData = new foo();
>> }
>>
>> judsimpl::OnStop(..., status) {
>>
>> if (NS_FAILED(status)) {
>> // shit hit the fan, if we had started the transaction, be sure to
>> clean up.
>> if (mMyPrivateData) {
>> // transaction had started because my otherwise null private
>> data has been allocated.
>> delete mMyPrivateData;
>> // do whatever else cleanup I need to do now that the
>> transaction is over
>> } else {
>> // transaction never even started.
>> // don't have to cleanup my init data.
>> }
>> } else {
>> // all went well.
>> if (mMyPrivateData) { // mMyPrivate data will always be non-null
>> here, but I'm being safe.
>> // transaction had started because my otherwise null private
>> data has been allocated.
>> delete mMyPrivateData;
>> // do whatever else cleanup I need to do now that the
>> transaction is over }
>> return rv;
>> }
>>
>> As you can see, you can almost ignore the status code in this case
>> and just use the mMyPrivateData var as a boolean check as well. I'm
>> not seeing any complexity here. nsresult codes already are broken
>> into failure and non-failure ranges (macro'ized via NS_FAILED() &
>> NS_SUCCEEDED())
>>
>>> 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.
>>
>>
>>
>> lol. why oh why don't I read all my email before diving in :-). You
>> got it! The error code can be useful though (say you wanted to throw
>> a dialog indicating what the error was for example).
>>
>>>> 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.
>>
>>
>>
>> exactly!
>>
>>>> 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.
>>
>>
>>
>> we'd need to clean that up too obviously.
>>
>> Jud
>>
>
