Dev/Config

From Eggdrop Wiki

Jump to: navigation, search

This page is intended for brainstorming ideas about changing the configfile concept.

Contents

Facts (current)

  • The configfile has more than 1400 lines and it's expected to grow even more while we introduce new features.
  • The configfile is arranged according to which settings belongs to which module (core, server.mod, irc.mod, ..)

Problems

  • Configfile is way too large, those who are familiar with it skip huge parts and just set what they need - they know the setting names and search for them.
  • There are those who are unfamiliar with eggdrop and IRC and don't understand half of the configfile, but they feel they need to change stuff (like my-ip) although they almost never should. (They set my-ip because they read 'put here your ip' and they think they know it, so they fill it in - it's suggestive 'fill in whatever you know'). They still miss those that they *have to* change like listenport.
  • There's no way to tell which setting has a sane default and which hasn't.
  • The configfile contains settings that are so rarely used, I'd say we could just as well remove them.

Workarounds by users

  • Config generators (they prompt for some values, generate a configfile - mostly stripping all comments)
  • They split the configfile into multiple files - one with usual defaults for their bots, and one for bot-specific settings (nick, server, botnetnick, ..)
  • Using the old eggdrop.simple.conf
  • They obtain a pre-configured eggdrop.conf from google, a friend, a random person on IRC, etc, usually not ending well.
  • They re-use an old config file that has worked for them in the past, possibly missing important changes made to the config between eggdrop releases.

Solutions/Ideas

Group by module - single file (Leave as is)

The current situation.

Positive:

  • Not loading a module means you can skip that section in the configfile

Negative: See section "Problems"

Group by module - multiple files

Positive:

  • Not loading a module means you can skip that file (we don't even need to install it when the module wasn't compiled)
  • 3rd party modules can add their configfiles to that system

Negative: See section "Problems" (mostly)

Group by experience - multiple files

Has been tried before (eggdrop.simple.conf, eggdrop.advanced.conf, eggdrop.complete.conf)

Positive:

  • Has something for beginners (.simple.conf)
  • Still offers the full featureset to those who want it (.complete.conf)

Negative:

  • Static grouping into 3 groups of users, not suitable
  • Beginners never see what they could theoretically fine tune and what feature they miss

Group by feature (single or multiple files)

Example: a "botnet" section, a "ssl" section, a "irc network features" section, ..

Positive:

  • Users who do not plan to use ssl or a botnet (or don't know what it is) can easily skip it

Negative:

  • Not loading a module that partly influences that set of features doesn't remove the settings from those files

Group by importance (single or multiple files)

Example: put the most important settings to change, such as nick, servers, listen port, at the top of the file. Least important ones at the bottom.

Positive:

  • Beginners can clearly see what they have to edit for Eggdrop to function.

Negative:

  • Entire sections of the config file can't be skipped based on which modules are loaded.
  • Which settings are important, and which aren't, is subjective and likely difficult to decide.
  • This method is an incentive for users to just edit the settings that make the bot run and not even look at others, that might still be important for that particular user.

Write a config generator

Generate a config file by interactively asking questions to the user.

Positive:

  • Users will be presented with important things to change right in their face
  • It can ask which features the user wants and not ask about everything (ssl, filesys, botnet, ...)
  • It can generate the config in various different ways, single/multiple file(s), grouped different ways

Negative:

  • Requires development effort.
  • Can easily grow exponentially to ask too many questions if developers aren't careful.

Check the conf for common errors

Checking for common mistakes in the config file.

Example things to check for:

  • No listen port set
  • No owner set
  • Botnick set to default
  • Servers set to default

Positive:

  • Would be helpful to new users.

Negative:

  • Doesn't really solve the bigger issue.

Discussion

  • I think a config generator written in tcl would be the easiest and most powerful solution, still leaving open how to layout grouped settings based on modules and/or experience. I could imagine something like old ircu config (taken from old kernel config): Example session --thommey 02:36, 3 January 2011 (UTC)
    • I like this idea, but it does require a working Tcl installation, complete with tclsh, not just the library files. --Pixelz 22:35, 7 January 2011 (UTC)
      • This would actually not be written in Tcl, but using ncurses like the psybnc menuconfig or kernel menuconfig. That's way more readable, accessible and doesn't force users to walk through everything. The top menu could be something like "browse by modules -> <module> -> settings", and maybe some other grouping. link to a tutorial showing what psybnc's interface looks like--thommey 22:39, 7 January 2011 (UTC)
Personal tools