Skip to content
This repository has been archived by the owner. It is now read-only.

Migrate existing configuration endpoints to the unified configuration API #2000

Closed
thecodejunkie opened this issue Aug 10, 2015 · 7 comments
Closed

Comments

@thecodejunkie
Copy link
Member

@thecodejunkie thecodejunkie commented Aug 10, 2015

As mentioned in #1999 once the new unified configuration API is implemented, we need to migrate the various configurations that we currently have implemented. This issue is intended to track the progress of that work. If you identify a place that needs updating, please let us know. Each of these should be handled as separate pull-requests so we can perform the migrations in a controlled fashion and split between multiple authors

Things that should be migrated

  • XmlSettings (pull-request #2115)
  • JsonSettings (pull-request #2124)
  • DiagnosticsConfiguration (Bootstrapper method) (pull-request #2012)
  • CryptographicConfiguration (Bootstrapper method)
  • StaticConfiguration (@thecodejunkie WIP)
  • GenericFileResponse.SafePaths (@jchannon pull-request #2184)

Probably will be in 2.x, but not in 2.0

  • NancyInternalConfiguration (possibly?)
  • NancyConventions (static content, views, localization and so on)
  • RazorConfiguration (IRazorConfiguration + *.config stuff)
  • Mime type registrations (issue #877)
  • Nancy.Hosting.Aspnet custom *.config handler

Class naming

  • [Word]Configuration - for the configuration class
  • [Word]ConfigurationExtensions - for the INancyEnvironment extension
  • Default[Word]ConfigurationProvider - for the INancyDefaultConfigurationProvider / NancyDefaultConfigurationProvider<T> implementation

Branch naming convention: I suggest we use a naming convention for the branches for each of these migrations. My suggested convention is configuration-migration-xxxxxxx where xxxxxxx is the name of the feature that is being migrated.

@jchannon
Copy link
Member

@jchannon jchannon commented Aug 11, 2015

👍

@thecodejunkie
Copy link
Member Author

@thecodejunkie thecodejunkie commented Nov 17, 2015

Ping @NancyFx/most-valued-minions @NancyFx/owners these are all up-for-grabs, don't be shy 😋

@khellang
Copy link
Member

@khellang khellang commented Nov 17, 2015

We should call the xxConfig naming convention. All existing xxSettings and xxConfiguration (and others if there are any) should be renamed to follow the convention.

In terms of naming, my 👍 goes to

  • [Word]Configuration
  • [Word]ConfigurationExtensions
  • Default[Word]ConfigurationProvider
@jchannon jchannon mentioned this issue Dec 10, 2015
2 of 4 tasks complete
@thecodejunkie
Copy link
Member Author

@thecodejunkie thecodejunkie commented Jan 9, 2016

@NancyFx/most-valued-minions Feel free to pick stuff from the above list

@phillip-haydon
Copy link
Member

@phillip-haydon phillip-haydon commented Jan 9, 2016

It's long winded but I prefer Default[Word]ConfigurationProvider or Default[Word]ConfigProvider simply because Default implies to the user that it can be overridden.

@thecodejunkie
Copy link
Member Author

@thecodejunkie thecodejunkie commented Jan 17, 2016

Updated description to reflect what will be going into 2.0 and what will end up in subsequent 2.x releases

@thecodejunkie
Copy link
Member Author

@thecodejunkie thecodejunkie commented Mar 17, 2016

We've done what we want to get done for 2.0. Closing this. We can come back if/when we decide to migrate more

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.