Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Comments

Bart De Smet bdesmet Bart De Smet ​[MSFT::SQL::​Cloud​Programmabi​lity::Rx]
  • Bart De Smet: Inside Rx 2.0 Beta

    @Mike: There are a whole bunch of use cases. I'm surprised to learn about new customers using Rx in different ways every week. Most recently:

    • Data center monitoring scenarios - e.g. computing moving aggregates of CPU utilization, noticing peaks, etc.
    • Sensor and signal processing systems - e.g. collecting and processing data in smart grids, network centers, etc.
    • Robotics where queries over sensor inputs control servos etc. - e.g. we've seen queries being compiled into embedded code.
    • GPS processing systems to tame events of long/lat pairs - e.g. filter out noise, correlate with other data stores, etc.
    • Intrusion detection systems by processing historical logs and real-time data - e.g. logs of requests / IP address, try to find suspicious outliers.
    • Blending UI events with asynchronous requests to web services etc. - e.g. take input in a text box and launch async web calls for completion etc.

    The spectrum of places used has also grown signficantly. We started off by going into Windows Phone 7 as an API to help users process sensor data (accelerometer, GPS, etc.). In full desktop CLR, we've seen adoption ranging from client UI scenarios to server/datacenter workloads. We're seeing an increasing interest in the embedded space as well, including robotics. And we have Rx for JavaScript used in both client and server scenarios (e.g. node.js).

    Stay tuned and you'll see us "eat our own dogfood" in various places. Quite a few products today are shipping "powered by Rx" (most lately PowerView in SQL Server 2012, various online services in Bing, but also yet-unannounced projects), and the number is growing fast.

    With regards to debuggability, we've done a lot of work in this release to make callstacks readable, approachable, and understandable (see the blog post). This is just the end of the beginning of work we're doing in this field. So again, stay tuned!

  • Bart De Smet: Rx Update - .NET 4.5, Async, WinRT

    @ninjeff: One thing that would help is to have Task implement IObservable. Given that any multi-value concept has the single-value case covered too, that'd be a good way to think about it. However, in the synchronous case, there's no such implicit conversion between a multi-value thing (e.g. an array) that happens to have a single value and its contents (an "unpack" operation). Rest assure we are (and will continue to be) thinking about co-evolution and co-existence...

  • Bart De Smet: Rx Update - .NET 4.5, Async, WinRT

    @ligAZ: We're actively working with the PLIB folks on making Rx portable. The main thing required is to have IObservable available in all supported platforms. At this point, we can't commit to a time frame, but we're on it Smiley.

  • Bart De Smet: Rx Update - .NET 4.5, Async, WinRT

    @AdamSpeight2008: Remains to be seen. Notice the trend of reducing magic strings in pretty much every recent release of the languages (e.g. LINQ instead of queries in strings, dynamic instead of invocation calls with member names in strings, call info attributes instead of hardcoding the current member's name, etc.).

    Personally, to reduce the event conversion friction I'd invest in a conversion of events to IObservable<T> like F# does, but at this point there are no such plans.

  • Bart De Smet: Rx Update - .NET 4.5, Async, WinRT

    @felix9: The test code you saw on the screen is not flawless indeed. In general, it's possible for the sequence to produce an OnNext message before the Dispose call to the subscription occurs. The fix is quite simple though: use the Finally operator in Rx to run code after the sequence completes or gets disposed.

  • Bart De Smet: Rx Update - .NET 4.5, Async, WinRT

    @Jeff: While Task<T> would be a good fit for single-value asynchronous results coming out of the Rx APIs, there are a few things we don't want to get into.

    First of all, staying in IObservable<T> allows for further composition, which is very rich in the world of Rx. A typical example I always bring up is to apply the Timeout operator to the resulting sequence. With Task<T> you can do similar things using WhenAny or by using cancellation mechanisms, but it's less sexy.

    Secondly, by going to Task<T> there's an implicit change in scheduler affinity. Having the ability to control scheduling through the IScheduler abstraction and having a more free-threaded world is an advantage of Rx we don't want to loose due to implicit changes of primitives.

    Having said all of this, users can still go to a Task<T> object explicitly by using the ToTask operator. However, for the simple task (pun intended) of awaiting the result of such a single-valued observable sequence, support is right there in Rx to use "await" directly.

  • Bart De Smet: Interactive Extensions (Ix)

    @evarlast:Thanks for bringing the broken link to our attention. We'll work on fixing it. In fact, we have a new version of Ix available (v1.1.10823). Hiding the old version from the Download Center caused the link breakage. Sorry for the inconvenience.

  • Bart De Smet: Interactive Extensions (Ix)

    @PerfectPhase: TPL Dataflow has some overlap for sure, but at the same time the two technologies can work together using - as you mention - bridging facilities.

    The main difference is this: with Rx you get a very high degree of compositionality thanks to the composition taking place at the IObservable<T> level. If you look at that layer as the declarative layer, you can think of deeper layers in Rx as operational layers. Concepts that fit in there include subjects and schedulers.

    At that level, it's much harder to compose because of the much more stateful nature of the building blocks. You can already see this being the case in the Rx API where the binding operators meet their subjects, requiring different - imperative-style - interaction through the notion of IConnectableObservable<T>.

    Similarly, composition of things like "backpressure" on an observable channel using queues and producer/consumer interaction is much harder. Say you have multiple sources coming together and you need to throttle the rate at which things are being sent. How do operators propagate the signals required to apply backpressure etc? Typically you deliver those out-of-band with regards to the composed query operators, requiring quite some plumbing.

    All in all, your analysis of "high level down" and "low level up" is pretty accurate. It's much (to use an analogy with a different domain) like the contrast between the querying experience in an RDBMS versus leveraging ISAM style access. The level at which you glue things together is different, and hence you have different levels of high-level expressiveness and/or low-level control.

    The nice thing is you can mix and match the technologies depending on your needs. Also, preferences in programming style contribute to those decisions: functional declarative state-poor combinator-centric query style, versus a more imperative state-rich approach based on message-passing actor/agent style. And thanks to the bridges available on the building blocks, you can sandwich Rx inside TPL Dataflow and vice versa, if needed.

    Also make sure to have a look at the documents available on the TPL Dataflow website. Also see this discussion that summarizes some of the observations (pun intended) made here.

  • Bart De Smet: Interactive Extensions (Ix)

    @AdamSpeight2008: You're lucky I have some flights coming up pretty soon Smiley. In the meantime, here are a few things to think about. How do grouping and windowing operators compare to the idea of a multi-yield? What's the lifetime of the underlying enumerator in case you have multiple sequences that are artifacts of applying an operator over a shared sequence (such as multi-yield)? Think about both the acquisition of the enumerator as well as the disposal thereof.

  • Bart De Smet: Interactive Extensions (Ix)

    @scyonx: We'll work on providing more samples on the subject going forward. Stay tuned.