IBuilder , RequestDelegate, HttpContext

[Damian Hickey]

http://whereslou.com/2014/05/28/asp-net-moving-parts-ibuilder/

Is it me or is this a statement that MS are abandoning OWIN? Don't mean to be inflammatory and, at the end of the day, one can always 'adapt', but can't shake the feeling...

[Sebastien Lambla]

There are owin extension methods. I think what this means is that the interface approach that we didn’t want to see as part of owin is something the team really wants, and there has only been discussions about having a builder method that could replace that interface alltogether recently (relatively speaking).

I wish MS got involved in the discussion on the builder signature and standardized on that instead of IBuilder. I’ve expressed before that the extension method for discoverability is a must if middleware authors want to not take dependencies on extenral components while not being at a competitive disadvantage.

Question is, is that something MS would be happy to go with or have they set their mind on IBuilder (and IAppBuilder before it)? We’re still at the early stages so I hope this is still up for discussion.

--

Sebastien Lambla

s...@serialseb.com - http://serialseb.com

On 29 May 2014, at 08:54, Damian Hickey <dhi...@gmail.com> wrote:

http://whereslou.com/2014/05/28/asp-net-moving-parts-ibuilder/

Is it me or is this a statement that MS are abandoning OWIN? Don't mean to be inflammatory and, at the end of the day, one can always 'adapt', but can't shake the feeling...

--
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.

[Ryan Riley]

We should give this feedback directly to the team rather than discussing amongst ourselves.

---

From: Sebastien Lambla
Sent: ‎5/‎29/‎2014 7:52 AM
To: net-http-a...@googlegroups.com
Subject: Re: IBuilder , RequestDelegate, HttpContext

[Boris Letocha]

How I understand it: With AssemblyNeutral types IBuilder is better solution. They want to build what they think is most discoverable API without old compatibility burden.
Instead of not using interfaces they fixed problem with them through recompilation.

Dne 29. 5. 2014 16:27 "Ryan Riley" <ryan....@panesofglass.org> napsal(a):

[Sebastien Lambla]

Well that is certainly one way of doing it, now that the tooling can exist.

I think I’m a bit confused as to what it means for current sites? I don’t see us moving easily to .net 5 the apps that we’re currently building, does it mean that we’ll just not solve the builder problem for current code, or that IBuilder could also support it by embedding the IBuilder as part of a UseXxx extension method on that, or what?

Either way it seems the current plan doesnt have a nice solution to allow us to do the important stuff now (prepare for an all-owin world) because whatever we do it is dependent on what the contract of an IBuilder could be in 5, something I don’t feel we currently have much of a conversation with MS.

What’s everybody’s point of view on that?

--

Sebastien Lambla

s...@serialseb.com - http://serialseb.com

[Damian Hickey]

There is also the implication that MW is built on RequestDelegate and HttpContext

On Thursday, 29 May 2014 16:48:01 UTC+2, Boris Letocha wrote:

How I understand it: With AssemblyNeutral types IBuilder is better solution. They want to build what they think is most discoverable API without old compatibility burden.
Instead of not using interfaces they fixed problem with them through recompilation.

Dne 29. 5. 2014 16:27 "Ryan Riley" <ryan....@panesofglass.org> napsal(a):

We should give this feedback directly to the team rather than discussing amongst ourselves.

---

From: Sebastien Lambla
Sent: ‎5/‎29/‎2014 7:52 AM
To: net-http-a...@googlegroups.com
Subject: Re: IBuilder , RequestDelegate, HttpContext

There are owin extension methods. I think what this means is that the interface approach that we didn’t want to see as part of owin is something the team really wants, and there has only been discussions about having a builder method that could replace that interface alltogether recently (relatively speaking).

I wish MS got involved in the discussion on the builder signature and standardized on that instead of IBuilder. I’ve expressed before that the extension method for discoverability is a must if middleware authors want to not take dependencies on extenral components while not being at a competitive disadvantage.

Question is, is that something MS would be happy to go with or have they set their mind on IBuilder (and IAppBuilder before it)? We’re still at the early stages so I hope this is still up for discussion.

--

Sebastien Lambla

s...@serialseb.com - http://serialseb.com

On 29 May 2014, at 08:54, Damian Hickey <dhi...@gmail.com> wrote:

http://whereslou.com/2014/05/28/asp-net-moving-parts-ibuilder/

Is it me or is this a statement that MS are abandoning OWIN? Don't mean to be inflammatory and, at the end of the day, one can always 'adapt', but can't shake the feeling...

--
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-abstractions+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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-abstractions+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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-abstractions+unsub...@googlegroups.com.

[Louis DeJardin]

Guys! We love OWIN, and are following the progress, which has been fantastic. The issues being filed about a request connectionid, and conversations about an official IPrincipal or ClaimsPrincipal key, are all showing the governance process is working. Note - the vNext code already supports the latest thinking by exposing the pure OWIN signature to append middleware.

vNext supports all the same scenarios as KatanaProject. Using pure OWIN middleware in vNext, running vNext on top of an OWIN server (David often demos running vNext on nowin on his Mac).

Moving IAppBuilder out of owin.dll into our assemblies, and avoiding declaring OwinXxx types and namespaces are the direct result of following the recommendations of this group. 

But to be blunt for a second - about having IBuilder at all - we need to take into account the entry-level segment of our users. The 3rd party web fwks are kind of lucky in that way - 3rd party web fwks have a self-selecting audience that are comfortable with the technology they are opting into. That's one of the things I miss about doing Spark in hindsight - it wasn't for everyone and that was okay. At Microsoft, the stuff you do does have to be for everyone.

In other words... There's just no way we'll be able to ship web application project templates that take a 4-deep generic action signature as the startup method parameter. To be honest it's remarkable we've moved the needle as far as we have - to the point where building an ordered-list of middleware is a reality (compared to using web.config to add HttpHandler and HttpModule sub-classes.)

[Ryan Riley]

That's great news, Lou! Thanks for posting. The IBuilder approach is proven and working really well, and I'm excited to see you continuing to move things forward. Also, thank you for your continued support of OWIN. We'd like you all to stay involved, though I know you are all very busy with ASP.NET vNext. Please weigh in on the discussions. You at Microsoft often have some of the best perspectives because of the customers you are around. The rest of us can quickly fall into an echo chamber.

I definitely agree that the goal is not to force everyone to think about delegates. Now that the middleware definition is defined, I think everything is set for a lot of experimentation with builder styles. For my part, I think the builder signature is something every framework will need to adopt for itself. Too many possibilities exist for there to be a one, true way, imho. 

One thing we do still need to shore up is the app lifecycle. That's probably the piece missing to ensure that any builder will work with any middleware. We should probably launch a discussion on that topic very soon.

Thanks again for the clarification!

Ryan

To unsubscribe from this group and stop receiving emails from it, send an email to net-http-abstrac...@googlegroups.com.

[Sebastien Lambla]

Well, my point is: IBuilder solves the disco problem with extension methods, which is great. In katana, its on IAppBuilder we’re trying to get away from because of its external dependency and the lack of standards around actually wiring up an app.

After thinking about it all night:

- I suggest we specify a BuildFunc for owin v1 so people can attach extension methods on top of that to allow the discovery currently provided by IAppBuilder. As we already agreed to let IAppBuilder go, I don’t see how we can not do that, even with the intellisense problems reported previously. I believe that without this discoerability things just won’t happen, full stop.

- for an owin v2, we specify a subset of IBuilder that could take a MidFunc on its method, which puts it as feature parity with BuildFunc. Due to the lack of external dependencies, it would be possible to support both without having any crazy dependnecy trees.

I think IBuilder supporting BuildFunc is not gonna happen. I think people are going to resist BuildFunc which is putting us in a difficult position to support discovery by your average joe.

Now if there are other proposals around providing the discovery in a non-IAppBuilder owinv1 way, independent of what IBuilder will do, then I’m all for that.

As for using HttpContext/Request/Response, I’ve not looked at the “low-level interfaces” described in one of the posts, so maybe that can be investigated, or maybe it shouldnt because thats a concern inside each middleware. I dunno.

Now if we can stop either cheering or side-stepping those questions around IBuilder and BuildFunc and their interaction, and attack the actual problems to solve, maybe we can start moving forward with BuildFunc and do the work to transition people away from IAppBuilder as we said we would, for which we need a proposal. :) 

--

Sebastien Lambla

s...@serialseb.com - http://serialseb.com

[Sebastien Lambla]

Anyone with any feedback?

--

Sebastien Lambla

s...@serialseb.com - http://serialseb.com

[Maxime Rouiller]

Nope Seb. I agree with all your points.

Anyone with any feedback?

To unsubscribe from this group and stop receiving emails from it, send an email to net-http-abstractions+unsubscri...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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-abstractions+unsubscri...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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-abstractions+unsubscri...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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-abstractions+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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-abstractions+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Damian Hickey]

My 2c:

• Agree with defining a BuildFunc, despite intellisense problems. Nonetheless, IBuilder (and others) is going to be much more palatable to other the general users. Thus we should note in the spec that BuildFunc doesn't preclude others from doing other builder implementations and that middleware authors SHOULD create separate integration packages. (eg. WebSocketsMiddleware.OwinAppBuilder)
  
• With aspnet vnext on the horizon we could start to look at using AssemblyNeutral for owin v2 and revisit builders / delegates etc.
• HttpContext/Request/Response: as a middleware author I like using these (currently the MS.Owin one) inside. I ilmerge /internalize before shipping. From a spec perspective, I don't think we should be concerned with that.(Or am I mis-understanding you?)

Anyone with any feedback?

To unsubscribe from this group and stop receiving emails from it, send an email to net-http-abstractions+unsubscri...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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-abstractions+unsubscri...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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-abstractions+unsubscri...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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-abstractions+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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-abstractions+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sebastien Lambla]

Inline

On 13 Jun 2014, at 10:46, Damian Hickey <dhi...@gmail.com> wrote:

My 2c:

• Agree with defining a BuildFunc, despite intellisense problems. Nonetheless, IBuilder (and others) is going to be much more palatable to other the general users. Thus we should note in the spec that BuildFunc doesn't preclude others from doing other builder implementations and that middleware authors SHOULD create separate integration packages. (eg. WebSocketsMiddleware.OwinAppBuilder)
  
• With aspnet vnext on the horizon we could start to look at using AssemblyNeutral for owin v2 and revisit builders / delegates etc.
• HttpContext/Request/Response: as a middleware author I like using these (currently the MS.Owin one) inside. I ilmerge /internalize before shipping. From a spec perspective, I don't think we should be concerned with that.(Or am I mis-understanding you?)

That’s where I was heading. I dont have an issue with IBuilder with AssemblyNeutral, it’s a nifty solution, but supporting both that and a BuildFunc would help tremendously in building now something that will enable cross usage of components between v4 and vnext, which is what I’m mostly concerned with.

The fact that a builder provides an extra type of .Use with strongly-typed references is also fine, as far as it’s usage should really be reserved to inline or project code, and any usage of storngly-typed object models should be clearly deliniated as not being compatible with the spec, and losing those advantages.

The default bringing in dependencies on IBuilder and on a strongly-typed Env leads to dependencies left right and center, that’s what I hope won’t happen and was my biggest objection against katana as advertised in the various MS publications.

On Wednesday, 11 June 2014 17:58:36 UTC+2, SerialSeb wrote:

Anyone with any feedback?

--

Sebastien Lambla

s...@serialseb.com - http://serialseb.com

On 30 May 2014, at 11:31, Sebastien Lambla <s...@serialseb.com> wrote:

Well, my point is: IBuilder solves the disco problem with extension methods, which is great. In katana, its on IAppBuilder we’re trying to get away from because of its external dependency and the lack of standards around actually wiring up an app.

After thinking about it all night:

- I suggest we specify a BuildFunc for owin v1 so people can attach extension methods on top of that to allow the discovery currently provided by IAppBuilder. As we already agreed to let IAppBuilder go, I don’t see how we can not do that, even with the intellisense problems reported previously. I believe that without this discoerability things just won’t happen, full stop.

- for an owin v2, we specify a subset of IBuilder that could take a MidFunc on its method, which puts it as feature parity with BuildFunc. Due to the lack of external dependencies, it would be possible to support both without having any crazy dependnecy trees.

I think IBuilder supporting BuildFunc is not gonna happen. I think people are going to resist BuildFunc which is putting us in a difficult position to support discovery by your average joe.

Now if there are other proposals around providing the discovery in a non-IAppBuilder owinv1 way, independent of what IBuilder will do, then I’m all for that.

As for using HttpContext/Request/Response, I’ve not looked at the “low-level interfaces” described in one of the posts, so maybe that can be investigated, or maybe it shouldnt because thats a concern inside each middleware. I dunno.

Now if we can stop either cheering or side-stepping those questions around IBuilder and BuildFunc and their interaction, and attack the actual problems to solve, maybe we can start moving forward with BuildFunc and do the work to transition people away from IAppBuilder as we said we would, for which we need a proposal. :) 

--

Sebastien Lambla

s...@serialseb.com - http://serialseb.com

On 29 May 2014, at 22:37, Ryan Riley <ryan....@panesofglass.org> wrote:

That's great news, Lou! Thanks for posting. The IBuilder approach is proven and working really well, and I'm excited to see you continuing to move things forward. Also, thank you for your continued support of OWIN. We'd like you all to stay involved, though I know you are all very busy withASP.NET vNext. Please weigh in on the discussions. You at Microsoft often have some of the best perspectives because of the customers you are around. The rest of us can quickly fall into an echo chamber.

To unsubscribe from this group and stop receiving emails from it, send an email to net-http-abstrac...@googlegroups.com.