Straw poll: common HTTP types

[Ryan Riley]

Straw poll: does anyone think a common F# HTTP set of types would be a good think for us to adopt, or do you think freedom to do things differently, cooperating at the OWIN level, is preferable? Think on it over the holidays, please.

Happy holidays!

[Andre Dublin]

Absolutely because it creates a standard layer with a predictable and extensible api.  Especially when introducing F# as a web stack option to new comers, we want to make the implementation as painless as possible.  Look at Rack for example, that lead to Sinatra, Grape, Rails and more.

[Ryan Riley]

Since Ruby is dynamic, OWIN is Rack for .NET. Also, Rack came after and was back-ported to Rails. I think the same was true for Sinatra.

This will be different because types require additional buy-in or adaptation in existing frameworks.

[Andre Dublin]

Ah you are correct about Rack, I wasn't aware of that.

Now that I think about it some more, I feel like keeping the freedom to let others work at the OWIN level will allow frameworks to continue their development without forcing them to adapt or use our types and leaves the responsibility of keeping HTTP interfacing to each framework.  

Now to rebuttal my own argument I feel that we can develop and maintain these types through governance by committee, which could possibly lead to a technical steering committee if that seems sensible.

On Wed, Dec 23, 2015 at 10:28 AM, Ryan Riley <ryan....@panesofglass.org> wrote:

Since Ruby is dynamic, OWIN is Rack for .NET. Also, Rack came after and was back-ported to Rails. I think the same was true for Sinatra.

This will be different because types require additional buy-in or adaptation in existing frameworks.

--
You received this message because you are subscribed to a topic in the Google Groups "F# Web Stack" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/web-stack-fs/ZFpCetlO7XY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to web-stack-fs...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jerold Haas]

I have concerns with keeping things at the OWIN-level for my own self-interests. Having a typed layer would allow a certain project I'm working on to have a common typed interface with which I can work with any of the web frameworks we currently have, and permit compatibility for any new frameworks that arise in the future.

I feel if "our" typed layer to interact with OWIN would be considered "OWIN complete", I'm curious to know what blockers we'd be presenting to other frameworks that would impede their ability to change. Am I guilty of having a blind spot, here?

[Artem Koshelev]

What about HTTP/2, for example? Freedom to do things differently is in any way a good thing, and implementing HTTP/2 trickery can benefit from decent type system, but trying to interoperate at OWIN level, which does not support HTTP/2, may cause a problem, isn't it?

[Leo Gorodinski]

What about the types in System.Net.Http?

--
You received this message because you are subscribed to the Google Groups "F# Web Stack" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-stack-fs...@googlegroups.com.

[Ryan Riley]

On Saturday, December 19, 2015 at 11:13:39 PM UTC-6, Ryan Riley wrote:

Straw poll: does anyone think a common F# HTTP set of types would be a good think for us to adopt, or do you think freedom to do things differently, cooperating at the OWIN level, is preferable? Think on it over the holidays, please.

Happy holidays!

It's a lot later than anticipated, but a conversation over on Gitter reminded me to get back to this topic. @eulerfx's point about using System.Net.Http types is worth considering, though we may prefer a lower-level abstraction, such as that found in the new ASP.NET HTTP Abstractions layer in .NET Core. That's assuming we want to stick with Microsoft's design decisions.

I would personally prefer to design a common, lower-level set of types that could support OWIN but that could be targeted directly, by-passing the heap requirements incurred by boxing and un-boxing and taking advantage of possible compiler optimizations, pattern matching, etc. Both Suave and WebSharper already have types, and Arachne provides type-agnostic parsers for HTTP that may be useful.

My biggest reason for pushing this can be found in the above, linked conversation and the fact that so many of the existing "OWIN" middleware are not really OWIN compliant, are unnecessarily complex in terms of implementation, and relatively small enough to rewrite ourselves with more simplicity and correctness. I think we can plan and build a solid set of components, still potentially support OWIN if we decide it has value, and provide a very solid platform for building web applications.

If others agree, I think next steps are laying out what types we standardize, what components exist or need to be developed (starting with security components), and then finding volunteers to build these things. Thoughts?