New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate existing configuration endpoints to the unified configuration API #2000

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

Comments

Projects
None yet
4 participants
@thecodejunkie
Member

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

This comment has been minimized.

Show comment
Hide comment
@jchannon

jchannon Aug 11, 2015

Member

👍

Member

jchannon commented Aug 11, 2015

👍

@thecodejunkie

This comment has been minimized.

Show comment
Hide comment
@thecodejunkie

thecodejunkie Nov 17, 2015

Member

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

Member

thecodejunkie commented Nov 17, 2015

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

@khellang

This comment has been minimized.

Show comment
Hide comment
@khellang

khellang Nov 17, 2015

Member

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
Member

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 referenced this issue Dec 10, 2015

Closed

v2 Requirements #2160

2 of 4 tasks complete
@thecodejunkie

This comment has been minimized.

Show comment
Hide comment
@thecodejunkie

thecodejunkie Jan 9, 2016

Member

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

Member

thecodejunkie commented Jan 9, 2016

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

@phillip-haydon

This comment has been minimized.

Show comment
Hide comment
@phillip-haydon

phillip-haydon Jan 9, 2016

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@thecodejunkie

thecodejunkie Jan 17, 2016

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@thecodejunkie

thecodejunkie Mar 17, 2016

Member

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

Member

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 join this conversation on GitHub. Already have an account? Sign in to comment