Doug Turner wrote:
>
> Darin Fisher wrote:
>
>> Doug
>>
>> I think that while we're making all of these channel changes, we
>> should also consider doing away with the IsA relationship between
>> nsIStreamListener/Provider and nsIStreamObserver. This is not
>> necessary and it only complicates implementations that would like to
>> implement both nsIStreamListener and nsIStreamProvider. There is no
>> reason why we couldn't QI for the nsIStreamObserver interface and
>> only optionally fire OnStartRequest and OnStopRequest. This would
>> give channel clients greater flexibility as they could decide not to
>> implement nsIStreamObserver. Take FTP, for example, which doesn't
>> care about OnStartRequest and OnStopRequest when writing to the
>> socket transport. Thoughts?
>>
>> Darin
>
>
>
> Interesting proposal. FTP is the exception to the IsA rule. The
> relationship between the listener and the observer is not "has a".
> They really build off of each other as most consumers want a
> notification at start, at end, and when there is data. Would this
> simplify something you are doing?
Anywhere that we choose to derive from both nsIStreamListener and
nsIStreamProvider would be simplified, as we would not have to be
concerned with the ambiguous cast to nsIStreamObserver. This is what is
holding up my FTP changes. I expect to use a similar pattern in HTTP as
well as in other places. Take a look at nsInputStreamChannel for
another example.
FTP should really implement the stream observer for the AsyncWrite case
in order to respond to socket errors. The real issue here is the
pain/ugliness of having to deal with ambiguous base classes. I think it
could be cleanly solved by removing the IsA pattern.
Darin
