Comments

When I say API I'm not interested in how it's implemented, so all of the talk about FromEventPattern is static. What I'm talking about is the public API, in this case the signature of WhenReadingChanged (again, I'm renaming so the name doesn't give an indication of IObservable or Task). The question is whether WhenReadingChanged should return a Task or an IObservable. I'm maintaining it should return an IObservable.

You are, however, correct when you ask if my point is that ReadingChangedObservable could have been used identically in both the async version and the Rx version. That's precisely the point. By defining your API (ReadingChangedObservable / ReadingChangedAsync / WhenReadingChanged / whatever) to return an IObservable you can use it with either Rx composition (appropriate when composing streams) or with async/await (appropriate when composing the "next" event as was done in several examples here). Contrast this with returning a Task. If you do that, you've lost the stream and can only compose with async/await (actually, we're totally glossing over composing with ContinueWith... the key is that await works not on Task but on awaitables, and both Task and IObservable are awaitables). IMHO, nothing is gained by returning Task, but a lot is lost, so you simply shouldn't return Task here.

You can't change the framework. By API, I mean *your* API. In this case, the WhenReadingChanged (or name of your choice) extension method. You still seem to be missing the crux of this, though. "(2) whether we should implement our logic using RX combinators or language combinators" sure seems to be missing my point. By returning an IObservable instead of a Task I have not limited you to Rx combinators. You can still use async/await to compose. What I've done is made the API (WhenReadingChanged) usable by both language and Rx combinators.

The guidelines as I see how they should be followed:

1. If the legacy event is part of an EAP implementation, wrap it with a Task, otherwise wrap it with an IObservable.

2. When composing, if you're composing streams you'll use Rx combinators, otherwise you should prefer language combinators using async/await.

(2) is a little oversimplified, so there's likely exceptions to be found, but 1 seems pretty obvious and I see no room for variation.

BTW, your StartShakeWatcher example violates one of the tenets from earlier in this series. Async void methods and delegates should only be used for top level event handlers. One of the reasons for this is to allow the API to be composable, but once you take that into consideration your original IObservable implementation is probably the better implementation. *shrug* Regardless, I believe my point still stands and streams of events should be modeled at the API level with IObservable and not Task.

Let's change the name in your example to just WhenReadingChanged so we can use the same name for both the Task solution and the IObservable solution. Now realize that an IObservable is an awaitable and you're first example works whether WhenReadingChanged returns a Task or an IObservable. Returning an IObservable is more appropriate, however, because the event is recurring. IObservable can handle composition of recurring event streams, while Task cannot. So returning a Task limits usage, while returning IObservable does not, and both provide the same usability in your scenarios where you're using a Task.

// Shake detection using async (from a stream of Accelerometer.ReadingChangedEventArgs)
public async void StartShakeWatcher(Accelerometer accel) {
    var t = DateTime.Now;
    while (true) {
        // Doesn't matter if WhenReadingChanged returns a Task or an IObservable, this works the same.
        var e = await accel.WhenReadingChanged();
        if (Math.Pow(e.AccelerationX, 2) + Math.Pow(e.AccelerationY, 2) < 1.1) continue;
        if ((DateTime.Now - t).Milliseconds < 200) Shake(this, null);
        t = DateTime.Now;
    }
}

This set of screen casts has been interesting, but this is the first one I've got serious problems with. At a conceptual level, I think you're abusing Task. Events typically are expected to be fired more than once. The only real exception to this is an event that's part of the EAP pattern. You're StoryBoard example is an EAP scenario, and there I have no problems with replacing that pattern with the TAP pattern. In fact, the EAP pattern should be considered harmful at this point, and TAP should be used for all new code and all legacy async code should be wrapped. All of you other examples, though, aren't part of the EAP, and as such are expected to be raised multiple times. For this, Task is the wrong solution. IObservable is the correct solution, and Rx observables are awaitable.

At an implementation level, you also have problems. Your TaskCompletionSource pattern fails to handle exceptions.

Is there a reason you mention iTunes and RSS but not Zune/Xbox/whatever-it's-called-today in each of the entries here? Or why there appears to only be an Audio subscription there?

1 hour ago

Is there a dependency on Team System in order to use GitHub from Visual Studio?

If I've read the linked pages correctly, no. You can create just a local Git repository when creating a project, and you can clone a project from GitHub or anywhere else.

Was that a Surface Skateboard by the fridge?

I'm actually disappointed with the B&N and MS collaboration so far. A Windows 8 app, but no WP8 app? The Windows 8 app isn't all that spectacular, either, in comparison to the Kindle app (I'm a NOOK owner, and live in that ecosystem, so I'm not playing fan boy here). Then the most recent NOOK tablet was still an Android based system. Doesn't seem like much of a collaboration to me.

@felix9: That's too cool.

@SleepyDaddySoftware: Boy, did you miss the point badly. "So, it would be better for all stakeholders involved if IE implemented the google standard" There you go again. There is no standard. None. There's a draft proposal, but no standard. This is an important distinction.

Everything else you said I've already said I'm in total agreement on. TypeScript should have source mapping, and that source mapping should be (barring compelling reasons otherwise) based on the existing draft proposal. If the existing proposal falls short for some reason, first the proposal should be tweaked before abandoning for an entirely different proposal. That's how standardization processes work.