This project has moved and is read-only. For the latest updates, please go here.

Decouple Microsoft.Owin.Host.HttpListener from System.Net.HttpListener

Feb 18, 2013 at 5:50 PM
Edited Feb 18, 2013 at 5:59 PM
I'm deeply convinced that HTTP layer implemented by HttpListener should be decoupled by an abstraction.

I'm figuring something like this:
interface IOwinListenerEngine {
  Task<IDictionary<string, object>> GetEnvironmentAsync();
}
the first implementation will be the actual so that
DefaultEngine : IOwinListenerEngine {
  Task<IDictionary<string, object>> GetEnvironmentAsync() {
    // here we the HttpListenerContext is mapped to Owin environment  
  }
}
This will open doors to different IOwinListenerEngine implementations.

For example Firefly (https://github.com/FireflyServer/firefly) can be encapsulated into a type that implements this interface.

Over the time we can have more choices. Engine optimized to run in embedded applications, other optimized for *nix, other for very high workloads, etc...

Another advantage is increasing testability. We can completely fake the core engine of our new Microsoft.Owin.Host.HttpListener.

Giacomo
Feb 18, 2013 at 6:17 PM
Edited Feb 18, 2013 at 6:46 PM
Side note: Your polarity is backwards. The OWIN pipeline is invoked from the server, sending requests to the application. Your Interface requires an intermediary to ask the server for requests and then push them into the OWIN pipeline.

Yes, server plug-ability is important to Katana, that's why there is already a server abstraction pattern for 'self-host' servers. Any self-host server implementing this pattern can be used with the Katana tools. Microsoft.Owin.Host.HttpListener, Firefly, Microsoft.Owin.Host.HttpSys, and others implement this pattern. Here are some examples:
HttpListener
Http2
Firefly, slightly outdated

This enabled other servers to be substituted into your application, and if you're using Katana.exe, you don't even have to recompile.

There is also a test server for in-memory testing of pipeline and application components:
TestServer

Also, this pattern does not use an interface because that would require binding to a specific version of a specific DLL containing that interface.
Feb 18, 2013 at 6:36 PM
So to be clear the strategy is the following:
  • The important implementation sits entirely on AppFunc and your Owin stack.
  • If I need a compliant-host with some feature a switch to another host.
Catched the point?

Sorry but the link provided at moment could not be loaded "We encountered a problem loading ...".

So you expected this post...? :D
Feb 18, 2013 at 6:50 PM
Fixed the links above.

Yes, server implementations are expected to fulfill specific needs (perf, scale, feature set, etc.), so an application developer can choose the most appropriate server for their scenario. On top of that server they add middleware and frameworks to complete their implementation.
Feb 18, 2013 at 7:00 PM
Thanks for fixing the links.

I think that it would be great to have a wiki that (that targets developers) that clearly explains this concepts and provide basic but effective samples.

Not a sea of words... Sometimes a developer can greatly benefit from a snippet of code and some words.

E.g. this morning I've tried hosting NancyFX in Firefly (if anyone interested, here the gist). I'll provide also samples on Katana too.

Thansk again, Tracther
Feb 18, 2013 at 8:05 PM
It's coming, but we really aren't expecting many server developers so those samples are lower priority. The current projections (& priorities) are for thousands of OWIN app developers, dozens of OWIN framework developers, and only a handful of OWIN server developers.
Feb 19, 2013 at 10:45 AM

Again thanks for info...

I was talking in general to raise knowledge on the subject.
Mine included. :)

@gsscoder

Il giorno 18/feb/2013 21:05, "Tratcher" <notifications@codeplex.com> ha scritto:

From: Tratcher

It's coming, but we really aren't expecting many server developers so those samples are lower priority. The current projections (& priorities) are for thousands of OWIN app developers, dozens of OWIN framework developers, and only a handful of OWIN server developers.

Read the full discussion online.

To add a post to this discussion, reply to this email (katanaproject@discussions.codeplex.com)

To start a new discussion for this project, email katanaproject@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com

Feb 19, 2013 at 11:20 AM
Tratcher,
I want to add that all this clarification are invaluable for me, thanks. :D

I'm also changing my point of view on how to contributing here (in late sense to OWIN, than Katana).

I've a couple of ideas about an OWIN application. This will me make aware of various aspects and then grown understanding will drive me to make more useful propositions about Katana.

I hope that all my questions / reflections have not been a disturbance...

Regards, Giacomo