Microsoft.AspNet.Http and Microsoft.AspNet.Http.Core package names swapped

[Tratcher]

RE: https://github.com/aspnet/HttpAbstractions/issues/190

These two packages have swapped names. Http.Core now contains the abstract base classes for HttpContext, etc, and interfaces like IApplicationBuilder. Http now depends on Http.Core and contains an implementation of those base classes and interfaces with like DefaultHttpContext. Most projects will only need a reference to the Http.Core package.

Note that there is no longer an Http.Core namespace, the items from both packages have been put into the Http namespace.

[bitcrazed]

If your intent is for most projects to only need to reference the abstract base classes, why put them in a sub namespace? I can already predict that I (and likely many others) will forget this guidance and assume they need to reference Microsoft.AspNet.Http, not a sub-namespace.

Why not put all the concrete classes and implementations that you do NOT intend developers to have to refer to often in, for example, Microsoft.AspNet.Http.Impl or similar, leaving the abstract classes in Microsoft.AspNet.Http?

[khellang]

Uuuh... @bitcrazed, I think @tratcher mentioned that there is no sub-namespace. Everything is under the same namespace:

Note that there is no longer an Http.Core namespace, the items from both packages have been put into the Http namespace.

There are two different packages, which IMO is great. If you only want the contracts, grab Http.Core, otherwise, grab Http. Though I doubt most people will ever explicitly grab any of the packages. In most cases they'll be implicit dependencies.

[maxfierke]

I think @bitcrazed's concern (correct me if I'm wrong) is with the package name, not the namespace. i.e. that Microsoft.AspNet.Http.Core sounds like the package with a more concrete implementation.

I would personally argue that the current package rename makes sense. The Core indicates to me that it is a subset of the Microsoft.AspNet.Http functionality and thus suits the package well, as it will contain only the abstract base classes or Core.

[artganify]

I'm fine with having Microsoft.AspNet.Http as the package containing the concrete implementations as this aligns very well to the namespaces in the 'classic' .NET stack (e.g. System.Web.Http and System.Net.Http). Microsoft.AspNet.Http.Core however indeed implies that there are some concrete 'core components', not just abstractions. What about Microsoft.AspNet.Http.Base? On Apr 22, 2015 12:23 AM, "Max Fierke" notifications@github.com wrote:

I think @bitcrazed https://github.com/bitcrazed's concern (correct me if I'm wrong) is with the package name, not the namespace. i.e. that Microsoft.AspNet.Http.Core sounds like the package with a more concrete implementation.

I would personally argue that the current package rename makes sense. The Core indicates to me that it is a subset of the Microsoft.AspNet.Http functionality and thus suits the package well, as it will contain only the abstract base classes or Core.

— Reply to this email directly or view it on GitHub https://github.com/aspnet/Announcements/issues/7#issuecomment-94959987.

[bitcrazed]

Ugh. Apologies. Reading is hard ;)

Happy that there's no namespace splitting and yes, like @khellang, I like the idea of only having to bring in one package if I don't need the concrete implementation.

However, I would think it more logical to put the interfaces and abstract classes, etc. in, for example Microsoft.AspNet.Http, but put the implementation in something like Microsoft.AspNet.Http.Impl.

As a name, core tells me little about what's in a assembly/package/module.

[aggieben]

I happen to agree with the described split in the announcement :smile:

[adamralph]

How about being explicit? Microsoft.AspNet.Http.Abstractions