NEventSocket.Channels

[pragmatrix]

As discussed in https://github.com/danbarua/NEventSocket/issues/41 one of the next steps for NEventSocket is to separate the Channels API. The main reasons are:

• Keep an abstraction separation between low-level (Sockets) and high-level (Channels) functionality and evolve the Channels API without compromising the core functionality.
• Keep the core small and stable and independently testable.

So I've tried to separate them and tinkered around until the project was buildable again, it went straight forward:

• There is one dependency to the internal type InterlockedBoolean, which I suggest to either make them public or temporarily add an InternalsVisibleTo to AssemblyInfo.cs in NEventSocket.dll.
• In addition to the files below the Channels folder, the files OutputListener.cs and OutboundSocketExtensions.cs clearly belong to the Channels API. I'd suggest to keep them in the NEventSocket namespace. It's quite common to add new classes to namespaces that were introduced in dependent assemblies.

Then there is the packaging. it's probably best to introduce a second NuGet package named NEventSocket.Channels. To make that work, I guess that the Rx dependencies should be referred instead of ilmerged into NEventSocket.dll. I am not sure what was the initial reason to use ilmerge, but I am pretty sure that it will open a can of wormes if it'll be left that way.

Regarding tests, I have no idea yet :( I hope Dan has some ideas.

What do you think? Can we proceed with the separation, or is it just too early? Is another branch a good way to figure out if we can resolve all these issues, or is it better to just tag what's there with v2 and continue to work on the master branch.

[danbarua]

We ILMerge Rx in so that we only expose 'IObservable' on the public API, and then consumers of the library are free to use whatever version of Rx they are using in their apps - similar to how most libraries [should] ILMerge NewtonSoft.Json