Development/ModuleLoader

From Inspire IRCd (InspIRCd)

	This page has been marked as Development Material. Information posted here may be subject to change and/or only available in unstable versions of InspIRCd.

1 Module Loader Redesign

Module Loader Redesign

Introduction

As it stands currently, our module loader, while working - sucks monkeyballs.

It's a collection of code from 1.0 which has since been hacked onto, patched, and worked around so that, while it simply "works", nobody can understand it anymore! ;p

It is also over-complicated in that we have module factories.

Contact

Om is the primary contact person for this

Module Factories

These are present to enable modules to have > 1 module to a file (..wtf the point of this is, no idea).

As I summed it up in a recent conversation..

<w00t> do we have any consensus on this?
<w00t> the only reason i'd vote to remove now
<w00t> would be:
<w00t> 1) they aren't used
<w00t> 2) they complicate the module loader
<w00t> only reason to keep:
<w00t> 1) they may be useful, sometime, we don't know when
<w00t> so, from my perspective, remove

So, they will be removed. Note that this will not impact any existing modules, provided they use MODULE_INIT like any good module since about 1.1.10 should.

Module Dependancies

I would like these better handled in 1.2.. and have a suggestion for how to do so.

We read conf, and instead of loading modules straight away, put them into std::vector.

Upon loading the actual modules, store a state bool success with each module. Loop through the vector trying to load modules until *all* return state fail, and then report errors from loading those modules.

This way, order in config becomes irrelevant.