i think we can all cut Demis some slack, since in the dotnet core, i see no reference to OWIN anymore. Only microsoft builder, microsoft hosting and microsoft abstractions.(apparently microsoft does take over every project, eventuely?). why do i say this? i dont see any dependencies on owin for the microsfot.kestrel package https://www.nuget.org/packages/Microsoft.AspNetCore.Server.Kestrel

I guess it could be possible to see if ServiceStack could run on kestrel instead of the SSselfhosting,or if selfhosting could be wrapped to implement microsoft.aspnet.core.
but in either cases it would only bring choice to how you would run your servicstack. i don't think this will be any priority by demis himself, maybe someone in the community could pick it up if he would so desire to fiddle around.

Demis, I want to apologize for everyone else on this thread who has given you and SS so much flak. They obviously don't understand the beauty of SS and how other frameworks like OWIN and Nancy compete with SS. Like you, I see no benefit in using these frameworks together. Doing so just adds unnecessary complexity which SS tries to avoid. Thank you for your patience and creating such a rich and elegantly simple platform!!

Hi Dennis, looks like Nowin is a good OWIN hosting option, and it seems it runs on both Windows and Mono too: https://github.com/Bobris/Nowin

The current status of OWIN is that it's on hold until further notice. It will be reconsidered once a superior HTTP hosting option becomes available.

I'll no longer be spending any more time discussing this feature request until then.

Darren, OWIN support is not just a "tacked-on" feature it's a design/directional change in both dev UX and impl that is not going to being considered lightly. I've already spent a lot of time discussing my thoughts on OWIN below. If I thought it was going to provide a superior development experience it would be supported already. Please understand the concepts and design in ServiceStack's AppHost, Plugins, Request Pipeline, etc represent what I believe the ideal API looks like, and whilst it would be nice to ditch everything and move to a superior design, I'm not seeing that in OWIN's delegate or Builder APIs.

This UserVoice site contains a list of feature requests that serves as a guide of what to implement in future, tho there's no public roadmap being committed to for much of the same reasons mentioned here: https://github.com/holman/feedback/issues/534#issuecomment-41705425

Release notes for ServiceStack features will continue to be published at:
https://github.com/ServiceStack/ServiceStack/blob/master/release-notes.md

Hi Demis

You mention 'it's just a 1-line configuration to tell ASP.NET to route all requests to
ServiceStack, from there you use ServiceStack's pipeline', but of course all those old webforms dlls are already loaded by that point.

I believe the benefit for having ServiceStack OWIN support (whether ultimately running under IIS or not) would be no longer starting through the normal ASP.NET (System.Web) request processing pipeline, allowing increased 'throughput' for large-scale apps:

http://blogs.msdn.com/b/webdev/archive/2014/02/18/supplemental-to-asp-net-project-helios.aspx

I see the microsoft just wrap System.net.httplistener at the moment in their OWIN implementation so clearly quite a few core dlls get loaded still, just not all the old webforms stuff.

http://msdn.microsoft.com/en-us/library/microsoft.owin.host.httplistener.owinhttplistener(v=vs.113).aspx

http://katanaproject.codeplex.com/SourceControl/latest#src/Microsoft.Owin.Host.HttpListener/OwinHttpListener.cs

You mention 'OWIN also brings it a bunch of complexity that most web developers don't (or should have to) know about'...but *ideally* I really don't see why they would have to know about it, other than just a different one line configuration?

I suppose there are edge case concerns with API surface, such as you mention you expose IRequest.OriginalRequest below.

What I am reading from your answers is that it is likely to be lots of work and you would rather focus on features that you see as addding more value. Fair enough, it's good to reassure those that you will consider later though...either to reassure them they 'made the right choice' or if they are considering the pros and cons now that servicestack v4 is not open source. Do you publish a roadmap anywhere?

Question.
as I read the following posts
http://www.cloudidentity.com/blog/2013/12/10/protecting-a-self-hosted-api-with-microsoft-owin-security-activedirectory/?utm_source=feedly
and this
http://dhickey.ie/post/2014/01/04/Protecting-a-Self-Hosted-Nancy-API-with-MicrosoftOwinSecurityActiveDirectory.aspx
It seems that if ServiceStack supports OWIN, we will be able to use Microsoft Azure Active Directory for authentication ?

I would simply change this request to make it easy to self-host Signalr + SS together on Windows and Mono. Maybe make it a separate nuget package.
You could also imagine something like wordnik's swaggersocket protocol that brings them together for some use cases...
https://github.com/wordnik/swaggersocket

Again, I've been doing this and it has issues and makes me want to use another framework even though I think SS is superior.

"But I do expect something to be happen soon, so will re-consider support for it then.".....that is good answer. My point entirely...you will have OWN support, it is just a matter of when (And why).

Eh? How exactly does ServiceStack become easier to replace if it was based on OWIN? It has no effect to how you would implement your services, how you register your dependencies, it also doesn't effect the Plugin API, or makes it any easier to re-use ServiceStack's features, etc. Whilst OWIN does make it possible to swap out hosts, in ServiceStack this is just a matter of changing which base class your AppHost binds inherits from, which is hard to beat.

I see that "OWIN" is being thrown about as some magical marketing moniker, but its no panacea fairy dust technology and we're not about to let marketing set technological direction. I consider it a worse API vs every equivalent SS API, if in future we do see value in OWIN that justifies supporting it, we'll only be adding additional API's, it will not be replacing our existing user-facing ones.

It adds more layers of abstraction, would introduce more complexity and confusion whilst offering less flexibility in being able to access underlying APIs, all of which we're fundamentally opposed to. IMO our dedication to simplicity, being able to encapsulate complexity and choose technology which provides the most value with the least artificial machinery (that's easier to reason about) is what makes ServiceStack an enjoyable framework to use - we're not about to throw our focus in order to chase intangible marketing monikers.

I know ServiceStack tries to be a full-stack framework. But customers need flexibility and standard (OWIN). It is really hard for me to push ServiceStack in my company if it is not easily replacable. It is even not about technology, it is about marketing. Giving others an opportunity to replace SS at the same time gives a lot more opportunity for SS to replace other technologies, as SS is so good.

ASP.NET is changing itself. OWIN is the direction and the future standard. Please embrace OWIN. It is NOT just about technology.

I was after desirable use-cases that add real-world value. Using Nancy + SS together is not a real-world use-case given they're substitutes web frameworks. E.g. There shouldn't be any reason to use Nancy's static file serving over ServiceStack's, if there is than there should be a feature request for ServiceStack to implement it (the ServiceStack way). Should the need exist ServiceStack already supports being able to register your own RawHttpHandlers to circumvent request handling with your own. But I really don't like the idea of needing the complexity of running multiple substitute web frameworks together as I'd consider it a failure if developers needed to know of the competing mindsets of how each framework works in order to mix and match competing functionality from each.

Either way, ServiceStack has always supported ASP.NET's extensibility pipeline ASP.NET has had since the beginning with it's HTTP Handlers/Modules. All ASP.NET web frameworks that supports this can be used together, which is how SS + MVC is able to work together. The primary alternative web framework people want to use with ServiceStack (other than ASP.NET/WebForms) is MVC, which also doesn't support OWIN.

ServiceStack + SignalR is the only real world use-case I can see that might be useful since they are focused on different things. This can still be done with ASP.NET with the above hooks.

ServiceStack's mission is to provide a simple and powerful Services framework with minimal complexity, which is also what makes it very easy to reason about how it works. It already has its own a thin dependency-free IRequest/IResponse abstraction, at the same time it's very easy to access the underlying ASP.NET HttpRequest object with IRequest.OriginalRequest (likewise with HttpListenerRequest). Adding more abstraction layers in the middle of will make it much more difficult to access as can be seen with WCF's abundant layers of abstraction. I'm personally against adding unnecessary abstractions which is also the reason why ServiceStack makes extensive use of extension methods, so it can add functionality without adding any abstractions, which results in still being able to access the underlying API's without sacrificing any power or flexibility, whilst providing high-level intent-based API's.

OWIN also brings it a bunch of complexity that most web developers don't (or should have to) know about. Its complex async delegate signatures, what is the Katana project? what are App Builders? How does OWIN bootstrap? How can you share IOC's? OWIN also provides alternate ways to register custom logic which I dislike vs ServiceStack AppHost, Plugins, Handlers, Filters, Binders, etc.

So I don't like the confusion adding OWIN would create and need a very good reason to support it. Since OWIN started the 2 things I wanted to use was authentication support, (which I got sick of waiting for so ended up writing my own) and a high-performance alternative to HttpListener, which still hasn't arrived. But I do expect something to be happen soon, so will re-consider support for it then.

Demis,
I am no expert here, so if I am am mislead or mistaken, let me know. OWIN allows us to replace anything in the stack with any component. This is something you have embraced from the beginning as you make something to replace most of these things. However, at the highest level, you are tied to httplistener, because that is the only thing you can see available right now.

Suppose I wanted to use nancyfx.org to handle server-side markup and static file serving, service stack for the API. How can I do that? With OWIN, I can just plug all those in (if SS supported OWIN)

Ideally, we want to remove references to system.web.dll as that makes non-iis things hard to do. Fast forward a few years when there are many other options. I believe it is just a matter of time.

Are you saying I can currently use Katana with Microsoft.Ownin.Host.HttpListener, plug SS into that? And add Nancyfx?

Given frameworks like Nancyfx (and point is future frameworks that come out, see list below), they support httplistener of course...because that is how you do it today with IIS, etc. In addition, they allow you to hook up to an OWIN framework, and that may or may not be based on HttpListener. You could write an article on how exactly to plug in SS with each of these frameworks (if even possible) or you could just support OWIN.

Not sure why the resistance to removing your system.web dependency and moving to a standard way of managing the pipeline.

Wayne, please be specific in exactly what must-have features OWIN provides that's missing in ServiceStack. i.e. OWIN still only supports self-hosting with HttpListener which ServiceStack has offered for years with its support for HttpListener hosts (which also requires a lot fewer dependencies).

Demis, it is only a matter of time before you have to do this in my opinion. If people do not want to use IIS, they cannot use SS because of you not supporting this.

Your call...

I'm more interested in making ServiceStack and SignalR work well together. I've done prototypes with the above as a reference, but surely there could be an easier way. SignalR does realtime very well, SS does REST API very well. Please make it not an annoying pain for them to work well together. OWIN seems like the appropriate way to make that happen. Even if the API is not to your favor, it is good for .NET ecosystem to have an agreed upon standard to interact with each other.
Currently SS is missing from this list:
Nancy
SignalR
WebApi
FubuMVC
Simple.Web
DuoVia.Http

I'm about to start another greenfield project, we need self-hosting in a .exe, and we need a REST API and a realtime API (SignalR). It looks like we'll be going with Nancy for this one though SS would have been preferable.

Here's another reason to support Owin :) -- http://weblog.west-wind.com/posts/2013/Nov/23/Checking-out-the-Helios-IIS-Owin-Web-Server-Host

1 line configuration for IIS 6 or 7 as shown here:
http://www.servicestack.net/ServiceStack.Hello/#rootpath
And an example of hosting ServiceStack + SignalR together using the standard ASP.NET configuration that's been around for a decade: http://www.strathweb.com/2013/03/signalr-filters-and-servicestack/

Hosting a bunch of different frameworks together is the very definition of un-necessary complexity, why should anyone have to learn 3 different frameworks when they can just learn one? IMO having multiple competing/contradicting heavy fx's is what's wrong with .NET, actually the whole ASP.NET stack is a complete mess, and has been making other web platforms look good since 2000.

I'm really not concerned with what other frameworks are optimizing for, if a feature doesn't provide much value, or is an uncommon/ non-realworld scenario, I'm simply ignoring it, I've got a tonne of better value-adds I'm spending my time on. Maintaining an intuitive framework means saying NO a lot - so I don't mind not supporting every use-case as long as the ones I care about work like water.

I'm still undecided on OWIN, I've been following it and waiting for the high-performance stand-alone HTTP server replacement for HttpListener for over 2 years, once that's released and shows a noticeable improvement over HttpListener (and runs well on Mono) I'll look into it again. I personally dislike OWIN's API, and I'm not in any rush to expose any new concepts/complexity or in-decision on how best to configure ServiceStack to our user-base.

Yo said: "...it's just a 1-line configuration to tell ASP.NET...". How about the following:
- I would not like to use IIS or Asp.Net for that matter (to manage IIS can be a complex matter, and sometimes you dont have IIS or you are not allowed to manage it). I would not use the asp.net projects in VS... But mainly I would like to do application composition, example: I would like to hook SignalR, Nancy and ServiceStack in a single processing pipeline (usually organized by the middleware, today this is Katana). Actually it is a classic example, but it is doable today using WebApi (and I would like to use SS instead). In this case the middleware is simply a router, and different functionality like services (SS), notifications (SignalR) and a web site (Nancy) are delegated to the respective workers.