Project K

[Mark Rendle]

So now the Project K stuff has actually been announced, is it time to start the discussion about how that affects OWIN?

My thoughts have been that the new Assembly Neutral Interfaces might offer a more strongly-typed way to spec what is currently the Environment Dictionary, but could become the Environment ANI? Would obviously make the whole thing much easier to work with.

I don't know the situation regarding ANIs in Core CLR, whether they're going to be supported in that environment or whether they are specifically a K thing. Anybody got any info on that?

Cheers,

Mark

Mark Rendle

Founder, Zudio

[Sebastien Lambla]

Any reference material?

Also, we don’t really have a compat target for owin currently, and anythign that involves only supporting the latest and greatest fills me with concerns.

As far as impact on owin, I would tend to think that’s an owin 2.0 question, and owin 1.0 could get us very far before we have to investigate the latest greatest models.

The conversation I’d like to have with MS is, is there a point in a delegate-based builder signature so we can start having middleware and frameworks expose themselves as extension methods without introducing the current out of the box dependency on IBuilder or IAppBuilder, or if they have little interest in moving away from the builder interface solution and that work ought to continue for everyone else, or if no one cares and we just leave the status quo we currently have.

If any blue badge wants to give us some insights in that (in a constructive fashion please!), that would be a first good step.

--

Sebastien Lambla

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

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

[Sebastien Lambla]

For those that didnt see it, something that makes me rather happy is the use of BuildFunc in the code in the aspnet owin project.

Now the real question is, is there anything missing from BuildFunc that can be achieved with IAppBuilder/IBuilder and is this an oversight that would lead middleware authors to attach to IBuilder rather than BuildFunc.

Any feedback from y’all would be useful. I’ll add an Issue on github with a summary of the BuildFunc discussion and proposed options as a starting point and we can start the conversation.

--

Sebastien Lambla

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

[Mark Rendle]

Yeah, I saw that, made me smile too.

I can't see how there could be anything about the IBuilder interface that makes a difference, since it's just "interface IBuilder { void Use(object obj); }". The issue is with the Katana implementation of IBuilder, and that various things rely on Katana rather than the interface. SignalR is a good example in the current versions. I managed to get it working with Fix, but only by copying big chunks of code out of Katana.

One thing that does concern me is the startup env, the the one supplied by the HTTP server that is used during initialisation, rather than the per-request env. I think there needs to be more discussion around that, and guidelines for how it should be used by various components.

M

--

Mark Rendle

Founder, Zudio

[Sebastien Lambla]

From my exploration of this issue, I can see how one would want to have BuildFunc = Action<Func<IDictionary<string,object>,  MidFunc>>

That would let you write:

public static BuildFunc MyStuff(this BuildFunc builder) {

  builder(properties => new MyMiddleware(properties).Invoke);

}

There is an additional advantage to this signature, it allows you to delay the actual initialization (and loading of the server property bag) until you are happy that you have collected all needed information about how to wire things up.

This would allow me to reintroduce the automatic http pipeline reordering that I need for the OR-compatible builder. It would also allow a back channel for middlewares to report information about themselves (with a special set of keys “owin.currentMiddleware.*”) which the builder can swap in and out as it gets called, potentially helping the glimpse guys by providing diagnostic keys.

Any other alternatives out there? I’d like to propose some text for BuildFunc today to start getting the ball rolling. It would be nice if everyone could share with us the things they use (and intend to use) the .Porperties on IAppBuilder for, what the design decisions have been and what must exist.

--

Sebastien Lambla

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