The Owin spec.

[Itai]

Hello

I'm a bit confused with the various Owin definitions (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 the definitions:

 

I think the attempt to convey the flow of information in definitions is to much digest and results in wording like “owin semantics” which is 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)

 

-Itai

[ryan....@panesofglass.org]

Itai,

Thank you for the feedback! I think you raise some good points. The best way to suggest changes to the spec is to create a new issue or send a pull request to the spec repo at https://github.com/owin/owin. The spec is now formatted in markdown for easier editing and pull request submissions.

I would like to clarify the reason for at least specifying some application level semantics. We intentionally avoided this early on because we wanted to keep the spec simple, as you express below. We then found that many middleware implementations were not compatible with the handful of host implementations. We therefore resolved to address this in the spec, which is currently still a to do item.

Regards,

Ryan

Sent from Windows Mail

--
You received this message because you are subscribed to the Google Groups ".NET HTTP Abstractions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-http-abstrac...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Itai]

No problem.. I will repost as an issue.

If I understand you correctly the middleware/host compatibility problems are mainly around integration? Then again I find this a matter to be addressed by a standard setup interface that servers/handlers must adhere to regardless of how the solution is ultimately defined for end users (e.g web framework/webapp/webservice/filter/module/plugins etc ... ). 

Regards,

-Itai