Move IAppBuilder to Microsoft.Owin #19
Comments
|
-1. If it's going to be moved, Project Katana is not the place for that. |
|
I agree it causes some confusion, but IAppBuilder can't be moved without resetting the ecosystem. I also wouldn't want to move it until there was an official replacement, so we could avoid breaking the world twice. I also agree with Tugber, Microsoft.Owin is not the pace to put it. Owin Contrib, in something named Owin.AppBuilder might work. |
|
What uses this outside Katana? It is, as far as I know, Katana specific. |
|
Also, there can be no replacement for an undefined spec. That this assembly exists is an historical accident/mistake. |
|
I see two problems here:
I'd like to see a proper builder spec written so we have a consistent way to use middleware with hosts. And, like OWIN, it shouldn't be dependent on type creation (but neither should prevent it). Renaming the DLL and the NuGet package would be good, but it doesn't solve the actual problem of |
|
This is a simple matter of versioning. Owin.dll 2.0 = empty assembly :) |
|
How about taking this to the owin discussion list instead? |
|
I disagree that we need a builder spec. I agree we should finally define a standard for chaining these things, since that seems to be a pain point for some. Mark's delegate works, as does |
|
@panesofglass +1 to @half-ogre IMO. Not having a really concrete spec for builder is what is the cause of the problem. Even making the IAppBuilder a spec would solve 90% of the problems (I agree that it's not ideal, though). |
That's a builder spec. |
|
@tugberkugurlu why do we need a builder? That is an implementation detail, not part of OWIN. |
I'm obviously biased given where I work, but I much prefer to keep things on a repo where the context lives. |
|
I agree with @half-ogre |
|
How much of the community is represented here? This affects everybody. |
|
@Tratcher Most people are using Microsoft.Owin. I don't understand how moving this interface to Microsoft.Owin breaks people. Everything in Owin.Extensions already moved. How is this different? Also, please note that we (inclusive of those on the Twitter discussion) are not saying If this can't get resolved, it is my opinion that the "Open" in OWIN no longer applies, and we (the community) will have to start working on the next OWIN since this effort appears to have been hijacked. |
|
+1 for |
|
@panesofglass MSFT has been putting a lot effort on OWIN based software and building great solutions. Honestly, I don't think I would care that much about the-next-OWIN that "the community" (which I'm not part of apperently :)) will work on. |
|
As for who is involved, the Twitter discussion included @skoon, @grumpydev, @serialseb, @darrelmiller, @jeremydmiller, @markrendle, and others, covering NancyFx, OpenRasta/OpenHttp, Fubu, Fix/Simple.Web, and Dyfrig/Frank (F#). I'd say that's covering most of the framework community. @markrendle and I also have server libraries that are trying to support OWIN. |
|
@panesofglass I need a builder spec so that the host that I'm crafting knows how to wire up the stuff. |
|
IAppBuilder was one of the early community proposals, it's not MS specific, it's just the one MS adopted. There are already MS independent implementations out there. It did unfortunately end up in Owin.dll without first being officially approved by the community. IAppBuilder can be moved to help clear up the confusion, but doing so is going to be a big break because .NET ties type names to assemblies. If we're going to make that break, I'd prefer to have a community replacement ready to move to so we only have to break the world once. |
|
@tugberkugurlu Great! Why can't that exist in Katana? It's a great implementation. What's requiring you have that in an Owin.dll? |
|
@Tratcher That was @loudej's recommendation. That was never accepted by the community at large. I recall the phone discussions acknowledging that was fine so long as it was not spec. Much of Gate moved to Katana. @bvanderveen helped, of course, but that was all still in the wild west days of the "Delegate of Doom" ™️ I understand now the impact. Thanks. I'm happy to make the move once we settle on a common replacement. |
|
@panesofglass Having a stable software is one thing that I'm all for. If the community you are talking about releases a software which doesn't step outside of the v0.* for years, I'll stick with the MSFT solutions which seem to be pretty robust and have stable release cycles. I don't think spiting the commutiy into two will solve any of these problems and I don't also think most of the people will care about only community driven the-next-OWIN. |
|
Assuming the community can finally standardize the startup sequence, there's no reason Katana would need to keep Owin.dll / IAppBuilder either. We use it for lack of a standard alternative. We don't want to fork the community either. |
|
@panesofglass as @half-ogre said:
that's the builder spec. |
To be clear, I'm not saying we should specify how a builder is implemented. I'm saying we should specify how a middleware is used in a builder, in the same way OWIN specifies how an app is used (the |
|
@Tratcher We are in agreement there. I think specifying the startup sequence would be very useful. However, it still has to be fairly generic. @tugberkugurlu I think it's terrific to use the Microsoft sponsored bits. I've already used Katana on several projects at work, and I'm about to do so again. This is hitting up against another issue, which is interop among OWIN implementations. Most fell behind b/c the v1.0 spec launched forward, and Katana was the first to get there. The rest of us have full-time jobs other than building frameworks. That doesn't mean we should have to fall in line with whatever the first mover decides. OWIN started as a community-driven solution to a common problem for framework and server devs working on side-projects part-time. Microsoft's involvement is highly prized and appreciated. However, that doesn't mean that they now own OWIN. We, the community, were willing to break compat with ASP.NET and IIS. I think we would be willing to do so again. I don't think any of us want to do that, but it's not really an issue for us since most of us have far smaller install bases. Honestly, I am not sure what you are arguing for. You seem to like Katana, and that's great. If Katana satisfies, then what are you proposing? Are you trying to build your own implementation? Do you want to use other implementations? I'm quite confused. |
|
So, are we official re-convening the OWIN community to address startup? Finally? If so, I might also suggest reviving the conference calls. They were very useful the first time around for getting everybody on the same page. |
|
For reference: Here is a discussion from last year about the |
|
As of today, the proposal to sunset the OWIN.dll containing IAppBuilder is passing 13-0 I think we can close the voting on this and discuss revamping the documents to provide a way for users of IAppBuilder to migrate to the current spec? |
|
Good stuff. Some time this week I'm going to find a minute to submit a pull request to M Mark Rendle On Mon, May 12, 2014 at 5:07 PM, Scott Koon notifications@github.comwrote:
|
|
Also, any text about the IAppBuilder should probably be a non-normative note released by the working group, as it was never part of the specification. |
|
I'm closing this issue. I submitted PR #24 to address the repository portions of this vote. I don't think we'll make any changes to the NuGet package except to possibly change the title to note that it will no longer be maintained (not that it needed maintenance). |
|
If pushing a new package (1.0.1?), should the interface be marked
|
|
If we push anything, we should push it as a major version so as not to break the world. |
|
What e
|
|
Whatever version, marking as obsolete would send the right message rather
|
|
Is marking something obsolete (with |
|
No, it's not a breaking change, that was my point, it should be false, with a meaningful message and not a major version change - that's what it's there for. |
|
Yeah, a simple message explaining why it's obsoleted and a link to a wiki article in this repo with a more detailed explanation and instructions on how to go forward sounds great. Also, if you were to bump major, would that be fetched with packages depending on >= 1.0.0? |
|
It would. They have to be restricted to less than 2.0 to prevent it.
|
|
+1 non-breaking change
|
|
+1 on marking it obsolete with a big warning.
|
|
Sounds good to me. I hadn't planned on pushing anything new to NuGet, but this recommendation sounds good. +1 |
|
-1
|
|
People who treat warnings as errors aren't really our concern. We just put the info out there IMO, how they react is up to them. There is a replacement available. The func specified in the spec. :)
|
|
Sorry, are we discussing a new version of OWIN.dll which will just have an Obsolete interface in it and nothing else? Can't we just tell people? |
|
@markrendle That's exactly what you're doing by pushing a new version of the package. How would you tell people otherwise? The package with one interface is kinda the whole problem to start with 😉 Let's obsolete it and make it known that this is not the way moving forward 👯 |
|
Hmm. I'm back to thinking we just empty the source and make a note on the README and in the NuGet package's description that owin.dll is done. We should make OWIN easy to adopt, not force people to jump through hoops to make things work. My recommendations:
|
|
Okay, I've resubmitted my PR having added a note to the |
|
So to actually find out that owin.dll (or |
|
I think most middleware authors are either directly engaged or using the Katana abstractions. I'm open to other ideas, but ultimately owin.dll us already out there. No reason to try to rewrite history. I think we should just abandon it and advise people to move onto other options. -----Original Message----- So to actually find out that owin.dll (or IAppBuilder, rather) is deprecated, you have to either drop by this repository and read that note way down in the readme or open up VS or the NuGet gallery to read the package metadata description? I understand that you might read that if you're adding the package for the first time, but what about existing middleware? Are all middleware authors involved enough for the news to reach them? |
|
Heck I'm fairly certain all of them have posted to this issue.
|
|
I don't see what harm it would cause to push a new version with the |
|
@skoon Yeah, I thought that might be the case 😝 @panesofglass I'm not saying we shouldn't abandon it. I'm saying we should get the message across as best we can 😄 |
How about a 2.0 that has an obsolete on the current memeber and a new one that is compatible with BuildFunc? Either way, I’d say let’s delay any decision on the package until we have a BuildFunc spec and a “getting way from IAppBuilder” document ready.Sebastien Lambla On 24 May 2014, at 23:49, Kristian Hellang <notifications@github.commailto:notifications@github.com> wrote: Yeah, I thought that might be the case [:stuck_out_tongue_closed_eyes:] I'm not saying we shouldn't abandon it. I'm saying we should get the message across as best we can [:smile:] — |
IAppBuilder is not part of the OWIN spec and should not be included in an owin.dll. This just confuses people new to OWIN.
The text was updated successfully, but these errors were encountered: