jweber jweber

Niner since 2009


  • Reactive Extensions API in depth: Contract

    Hi Jeffrey,

    First of all, thanks for your answer: I'm now sure the options I listed are valid implementations from Rx point of view.

    And as the behavior of the IObservable depends on the choices made for the concrete type implementation, this also answers my second question.


    So yes, your answer helped.

    Thanks again (and please don't stop your "Rx in Depth" post series !)



  • Reactive Extensions API in depth: Contract

    Hi all,

    Regarding the contract, I'm wondering about the case where an IObservable<> represents a finite source of (uncached) external "events".

    Just imagine a postal service that exposes (for each handled letter or parcel) a member of type IObservable<DeliveryStatus>, where DeliveryStatus represents the location of the letter/parcel; whenever the barcode of the parcel is scanned, the location is notified to the subscribed observers; the IObservable<> is done (invocation of observers' OnDone() method) when the recipient receives the letter/parcel.

    My idea is that when a client application receives/gets this IObservable<> and subscribes a matching IObserver<>, the letter may already have reached its destination since seconds/minutes/days (my country has a very efficient postal service).

    Would each of the following be considered as an acceptable behavior?

    1- The observer never gets any of its members invoked.

    2- The observer's OnDone() is invoked on subscription.

    3- The observer's OnNext() is invoked with the final location, then OnDone() is invoked; both invocations being done on subscription.

    4- The observer's OnException() is invoked on subscription ("Parcel already arrived, dummy !")

    Is one of these behaviors preferable?


    Moreover, as a designer of such a "postal service notification framework", do I have a mean to force implementors to adopt one of the behaviors described above (1-4)? (I guess not)


    Thanks for your insight.