Dave Sexton

https://github.com/janvorli/coreclr/blob/a7cbc5c8d1bd48cafec48ac50900ff9e96c1485c/Documentation/project-docs/unloadability-howto.md Upon disconnection, unload the query. Cheaper than AppDomains, which aren't available in .Net Core anyway.

Currently, if you use the `QbservableServer.Create` method to accept arguments, the `IObservable` that is supposed to represents all clients' arguments is actually just a singleton observable that is instantiated once...

Notifications from clients arrive on I/O completion ports. Blocking these threads causes deadlocks and/or severe performance penalties. Therefore, allowing clients to close over enumerables, or synchronous functions of any kind...

Currently, the `ObserveOn` operator can only be used with serializable `IScheduler` implementations; however, this is not the typically intended usage of `ObserveOn`. Rather, its usage implies that the server must...

Research, and consider refactoring for performance.

Rename Query method to AsQueryable

2

Got some feedback from developers new to Rx who said that the name `Query` was confusing. I think I agree, but perhaps for a different reason: it seems to imply...

Consider having `TcpQbservableClient` (and its base class) implement `IQbservable` so that clients don't have to invoke the `Query` method at all, unless they want to pass in a subscription parameter.

Protobuf

1

Provide support for protobuf. (Separate NuGet package?) It would work something like this: 1. Client defines proto for itself. 2. When Subscribe is called on the Query(), the proto-aware transport...

Consider following the path of the Rx project and target only these platforms: * netstandard 1.3 * net45 * net46 * uap10.0 https://github.com/Reactive-Extensions/Rx.NET/issues/199#issuecomment-268425895

Create a PID operator that automatically throttles notifications from the server based on the changing performance of the client. For example, the operator could buffer notifications on the client while...