E2E: Erik Meijer and Wes Dyer - Reactive Framework (Rx) Under the Hood 2 of 2

Well I think there would be some restrictions (on types that can be used and method calls), that could be passed to the server.  But look at what ..net ria services, what it does is it takes the IQueryable expression tree and serializes it directly and sends it off to the server.  IQueryable is just expression trees that havnt been compiled into a function that returns an IEnumerable yet.  I am sure they could have a simlar thing in IObservable that would have interfaces like  IRequestable Select<source,result>(this IRequestable , Expression<Func<source,result>> ).  I dont know quite what they would call it though.  IQueryable unforchantly derives from IEnumerable, but otherwise it would be identical in its signatures.  IQueryable assumes that something is going to serialize it to pass it to something else for proccessing.  In the case of observables you would be assuming something is going to serialize it to do the proccessing (filtering or other proccessing) remotely.  Maybe something like you can pass it up to the server and have it tell you when some specific row of a database table changes, or off to active directory to let you know when some user gets locked out.  All the server does is provide you with access to everything you have access to as one giant IObservable, and then the client can select (and filter) the type of events it wishes to listen to, and only those are sent down.

Also intresting to think about this in terms of a UI framework.  Where the framework itself has one giant IObserable which sends a new value every time the mouses moves or keyboard is pressed, and it hands off to all its children .Where(...) verions of the giant IObserable that filter for just its selected area of the screen or currently selected child (which then wraps its children in another .Where).  In the end you dont need to even test do any hitbox testing or anything, everything just flows down stream.  I spose most UI frameworks like WPF already do this with thier visual tree's just invoking methods on a child of a known type (like UIElement), but when you look at the 100's of On... overrideable method calls, you got to wonder if filtering only what you need might be a better option.  Where they dont have to keep extending the base class to add additional method calls, and instead add new derived event types that return more specific infromation if you want that extra info.  Or say your a team like Microsoft Surface that has some specific type of "new" interaction events you want to pass to your children based on specific proprietary hardware.  In the current WPF, this is very hard/impossible (I think they derived thier own UIElement type and force all thier children had to derive from that to get the new events).

My guess unfortunately is they aren’t going to retrofit anything, at least initially.  We would be lucky to get the IObservable interface in the BCL (and not just as an extension), although this might happen in .NET 4.0.  If they actually went converted events to be IObservable’s they would break everyones code that depended on those events.  Even if they rewrote the compiler somehow so the event keyword now MEANS IObservable, a lot of code would break (think of the IL changes on a different language).  Ah well, the good thing is that at least all events can easily be converted into IObservable’s.