Owin terms

[ghost]

I'm a bit confused with the various Owin terms (e.g Web Framework, Web Application, Application)

Why not just state:
"OWIN defines a standard interface between .NET http servers and http handlers."

Whether a specific http handler implementation ultimately defines a framework or some simple processing routine seems like a different concern and orthogonal to the spec.

I mean why include application type semantics in a general interface?
Furthermore, I think the term “handler” is more straightforward than “middleware” as it clearly conveys the notion of responsibility and the general idea has been well established by ASP.NET ... I think the term OwinHandler/OwinHttpHandler is better.

You can even see such use in roy’s dissertation.

http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf

Page 133: "The resource is not the storage object. The resource is not a mechanism that the server uses to handle the storage object. The resource is a conceptual mapping — the server receives the identifier (which identifies the mapping) and applies it to its current mapping implementation (usually a combination of collection-specific deep tree traversal and/or hash tables) to find the currently responsible handler implementation and the handler implementation then selects the appropriate action+response based on the request content. All of these implementation-specific issues are hidden behind the Web interface"

As far as other definitions:

I think the attempt to convey the flow of information in definitions is to much for the reader to digest and results in wording like “owin semantics” which are not straightforward, definitely at that stage in the document.

I suggest keeping it simple like:

1. Server – A component that accepts client connections in order to service requests.
2. Middleware / Handler – A component responsible for processing client requests.

Then I would add something like:

This specification aims to define a standard API by which a Server component communicates with Handler component and vice versa.

I also suggest removing the Host definition as I don’t see how it contributes to the clarity of the spec. If we accept the use of the term “component” than it’s pretty clear that the context here is a computer process and avoid any ambiguity with the “Host” term in its most common use (e.g server / machine)

[panesofglass]

If we split the specs, as we have proposed doing, I think your term changes make sense. We could focus the primary OWIN spec on separation of server and handler. Our middleware spec could then dictate application-level semantics on the handler side. What do you think?

[ghost]

Sounds wise and an important step forward...

[darrelmiller]

I'd like to make a case for keeping the application/middleware distinction. I'm currently in soft 404 hell with a Web API application returning a 404 but an Owin host returning a 200. In my opinion, part of the problem is that there is not a clear distinction between what is middleware and what is an application.
As far as quoting Roy is concerned, in his description of the layered architecture of HTTP he makes a clear distinction between intermediaries and the origin server. The fact that Owin middleware tends to run in the same process as the origin server shouldn't change their architectural qualities.

Middleware components have the basic property of passing a request on by default. Under certain cases, they may intercept the request and return a response directly.

In my opinion, application components should be responsible for completely satisfying all requests passed to them, whether the result has a successful or unsuccessful status code.

Middleware routing components should be used to ensure that applications receive the requests that are intended for them.

Calling everything a handler encourages this strange model of an application that determines that it isn't responsible for that a particular URI and so passes it on to another application. However, there is no standardized way of communicating this desire and so we have implementations like Katana that have created soft 404s to deal with it.

[ghost]

I'd like to make a case for keeping the application/middleware distinction. I'm currently in soft 404 hell with a Web API application returning a 404 but an Owin host returning a 200. In my opinion, part of the problem is that there is not a clear distinction between what is middleware and what is an application.

I think we need to reconsider the spec scope before discussing what to keep or remove which is basically what I’m arguing for. I think that at its core the distinction between application and middleware (or both) is irrelevant to the spec.

As far as quoting Roy is concerned, in his description of the layered architecture of HTTP he makes a clear distinction between intermediaries and the origin server. The fact that Owin middleware tends to run in the same process as the origin server shouldn't change their architectural qualities.

I certainly don't want to change the discussion to a REST discussion... My intent with the quote was to simply show how the term "handler" was intuitively used as figure of speech for where actual request processing occurs in an established architecture. Nevertheless, I don't quite understand what conclusion are you drawing here from intermediaries/origin server and what inherent architectural qualities do middleware poses as opposed to handlers in the general scenes? (not ASP.NET handlers)

Middleware components have the basic property of passing a request on by default. Under certain cases, they may intercept the request and return a response directly.

So could those termed "handlers", they just don't suggest being in the "middle" of anything.

In my opinion, application components should be responsible for completely satisfying all requests passed to them, whether the result has a successful or unsuccessful status code.

What exactly is the take for OWIN as a gluing API?

Middleware routing components should be used to ensure that applications receive the requests that are intended for them.

The way I see it, the "application" is a collection of handler implementations (e.g "Middleware components"). The server, well is just a server be it iis, httplistener or some other socket based implementation. "Routing" is an app/framework specific concept.

Calling everything a handler encourages this strange model of an application that determines that it isn't responsible for that a particular URI and so passes it on to another application. However, there is no standardized way of communicating this desire and so we have implementations like Katana that have created soft 404s to deal with it.

1. Apart from the server, everything is a handler implementation, how you ultimately name it for your users is up to you (framework, webapp, filter...) and leaves out ambiguity from the model.
2. Handlers should be generally bound to url's so proper configuration should not cause overlap between distinct handlers that form different applications. Generally speaking, I see two type’s pass-through and terminating per url space (e.g /app1/, /images/) where each can possibly mutate the req/resp. Chaining independent handlers is a complex issue which requires further thinking/research... Here I think ASP.NET got it right by keeping the pipeline configuration separate from the modules/asp.handler implementations so it may be appropriate to go with this approach with the introduction of “handler order” that determines who gets the request first (e.g why should I call Next?). So I might have an application that’s comprised of two handlers’ orderly registered for /app1. How third-party handlers play together? Well if someone attempts to solve a general problem for any url space, he better be sure he solves the right problem without generating new ones :) I would start by REQUIRING clear documentation.
3. I don't quite understand how soft 404 impacts all this..

p.s

Markdown rocks!

[ghost]

Coming to think of it, might be a good idea to consult with IIS/ASP.NET folks on chaining aspects as they must have faced these types of concerns when designing the pipline.. may very well turn out to be a problem not worth dealing with.

[panesofglass]

Thank you for this dialogue. I think it highlights the different concerns we need to address and why, imho, one spec is insufficient to clarify all points.

OWIN started as a mechanical abstraction between servers/hosts and handlers/applications. For those confused by the term host, as I was up to a few days ago, a host is essentially a server adapter that allows running specific types of handlers, e.g. mod_mono running on an Apache web server. The mechanical abstraction is defined by the Func<IDictionary<string, object>, Task> delegate signature. This signature declares that a single host environment is passed in and a Task returned. This signature can in no way specify architectural implications as it is far too simple.

Middleware as intermediaries is an architectural abstraction. I think this equally important, especially from the perspective of interop between OWIN implementations and in setting the context for discussions such as whether shared state should or could be allowed across middleware components. The signature we agreed on, and which still needs a spec, is defined as:

using Env = IDictionary<string, obj>;
using AppFunc = Func<Env, Task>;
using MidFunc = Func<AppFunc, AppFunc>;

The MidFunc signature is capable of expressing a bit more architectural intent: that of a chain, or pipeline. The Func, in and of itself, should indicate that shared, mutable state is prohibited except through the provided Env environment.

Lastly, we've discussed a BuildFunc which is defined as Action<Func<IDictionary<string, object>, MidFunc>>. Here, the dictionary is not an environment but a property bag describing the features supported by the host/server. This signature specifies additional semantics and provides a way to share some level of state across middlewares in the middleware chain. I don't really know how to qualify this one, as it doesn't seem to address mechanical abstractions or architectural concerns, per se. It seems a convenience mechanism, which is fine but not something that demands a specification, at least not yet.

Do these breakouts resonate with anyone else? Is this a pattern we should follow in further defining and refining specs? @markrendle is planning to commence writing the middleware spec soon, so I think it would help to answer a few questions:

• Should the middleware spec actually be an architectural spec, with middleware as an element?
• What else would be long in such a spec? Web Sockets?
• Do we need to refine the current OWIN spec in light of the above to focus on mechanics?

[markrendle]

So this would essentially restrict the OWIN mechanical spec to describing AppFunc and the Environment dictionary, standard keys and so forth (effectively a Host spec, in fact), and introduce a new spec describing the way in which an AppFunc is built by combining middlewares and applications?

I guess it makes sense, it would keep the two documents more concise and relevant to different audiences.

I think Web Sockets would necessarily remain part of the Host spec, since it prescribes how the Host should provide the Web Socket upgrade delegate.

[ghost]

a host is essentially a server adapter that allows running specific types of handlers

Exactly! It’s an implementation requirement on existing servers to “speak OWIN” but now consider new OWIN servers implementations, these wouldn’t need any adapter as OWIN would be their “mother tongue”. My point being, that the spec should state what API is required to be compliant and no more.
If it takes to build an adapter (a.k.a Host) for some existing solution to "speak OWIN" then it’s the server implementer concern not OWIN.

Here is the difference in terms of block diagrams:

Existing Server:

[IIS Server] [OWIN Server Adapter] [Handler]
or
[IIS Server [OWIN Server Adapter]] [Handler]

New Server:

[OWIN Speedy Server] [Handler]

IMHO, OWIN at it's core/mechanical abstraction should simply be about Servers and Handlers which will make simple questions easy to answer like: does your server support OWIN? Is your server OWIN complaint ?

I can envision big potential for new OWIN Servers.. Indecently I did some research on java-based nio servers and found them popping out like mushrooms using custom memory allocators leaving the GC to take a backseat. OWIN can be a catalyst for such trend in .NET

[darrelmiller]

Itaid

Generally speaking, I see two type’s pass-through and terminating per url space

That is pretty much all I was trying to say. I just tend to be verbose when frustrated :-). That distinction is made by HTTP architecture and therefore I see value in making that distinction in the Owin spec. Whether it ends up being in one spec or two doesn't really concern me too much.

My reason for mentioning the soft 404 issue was to highlight the fact that because Owin doesn't currently clearly distinguish these two notions, we have implementations that use "terminating" style handlers to sometimes do passthrough to other "terminating" handlers. Personally I find this a confusing approach. However, this really is a Web API issue, not an Owin issue.

[serialseb]

+1 to this. If you remember, the soft 404 question was so painful that I left this group about it back in the days. :))

[panesofglass]

Closing this in favor of #24, which moves us closer to a resolution.