Skip to content
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

[RFC] Method of inheriting configuration values from other keys. #387

Closed
SadieCat opened this issue Dec 19, 2012 · 2 comments
Closed

[RFC] Method of inheriting configuration values from other keys. #387

SadieCat opened this issue Dec 19, 2012 · 2 comments
Labels
discussion Discussion about the behaviour of InspIRCd enhancement New feature or request

Comments

@SadieCat
Copy link
Member

I think it would be useful if there was a generic method of inheriting values from other configuration blocks. This is already implemented by various tags already (connect classes, oper classes/types, etc) but it would a lot less duplication if this was available at the parser level. Some ideas for how this could be implemented have been mentioned below.

Normal

<example name="xxx" foo="bar" baz="bax">
<example parent="xxx" foo="fooey">
Points for
  • Very easy to read
  • Would require almost no parser modifications
Points against
  • Could conflict with config key names
  • Not obvious what is a 'special' key and what is not

Namespaced Attributes

<example cfg:name="xxx" foo="bar" baz="bax">
<example cfg:parent="xxx" foo="fooey">
Points for
  • Would not conflict with 'normal' keys
Points against
  • Harder to read
  • Would require parser modifications

Namespaced Elements

<cfg:xxx foo="bar" baz="bax">
<example:xxx foo="fooey">
Points for
  • Would not conflict with 'normal' keys
  • Easier to read than namespaced attributes
Points against
  • Still slightly hard to read
  • Would require parser modifications
@SadieCat SadieCat changed the title [Proposal] Method of inheriting configuration values from other keys. [RFC] Method of inheriting configuration values from other keys. Jun 6, 2014
@Techman
Copy link
Contributor

Techman commented Sep 20, 2016

I vote option 1, because I wouldn't want increased complexity, even if slight, because the InspIRCd config itself is already hard to many beginners and we don't need something as simple (or complex, depending on what you do with it) as connect classes being the thing that pushes them away.

01:08:21 AM <+Techman> I like the current system

01:09:05 AM <+Techman> Anything not specified that has a parent="" also in the tag are options that should be inherited imo

@SadieCat
Copy link
Member Author

SadieCat commented Feb 4, 2017

Draft implementation: SadieCat/inspircd@master+config...SaberUK:master+config2

Usage:

<wibble tag-name="wibbly" name="foo.bar">
<wobble tag-name="wobbly" tag-parent="wibbly">
<server tag-parent="wobbly">

Which is functionally equivalent to:

<server name="foo.bar">

@SadieCat SadieCat modified the milestones: v3.0, v4.0 Aug 24, 2018
@SadieCat SadieCat removed this from the v4.0 milestone Nov 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Discussion about the behaviour of InspIRCd enhancement New feature or request
Development

No branches or pull requests

2 participants