From the makers of InspIRCd.

Contents 1 Introduction 1.1 1.2.0 Release 1.2 1.2+1 1.3 Future (to be done at some currently undetermined point) 1.4 Being Considered....

Introduction

This page is to provide a general roadmap for future InspIRCd development. It is updated regularly, so don't take it as verbatim.

Please note that this page may be quite technically oriented, as it is intended primarily as a developer reference.

Please only edit this page if you are a developer. :)

1.2.0 Release

It's quite long, so moved to a seperate page. See Development/Roadmap/1.2.

1.2+1

• Bug #539 - motd/rules creatable by remote includes
• Review of m_watch for duplicate code
• Review of chanprotect settings
• (w00t) Socket subsystem/buffering review
  • Flexible sendq: Don't rigidly enforce sendq, allow some flexibility e.g. for /who, /check, possibly /list output.
  • combine buffers via a simple structure w/ pointers to reduce string copies drastically? (keep ssl in mind, but should be ok now)
  • (done) handle all read/write buffering *internally* instead of making modules deal with it (this is very much possible now)
  • Make code IPv4/6 neutral (remove idfefs?)
• Move operoverride to a usermode priv (possibly one that times out after being unused for a while?)
• perl bindings
• Somehow(?) don't blow users up for forced nickchange w/ +N etc? Bug #607 - annoying w/ svsnick, etc.. hm..
• Allow OperOverride to set modes +qa Bug #524
• protocol changes:
  • switch to using EUID from charybdis? or UID from TS6?
  • FMODE -> TMODE from TS6 (they are identical in scemantics already)
  • FJOIN -> TS6 SJOIN compatibility somehow?
  • Split riding: handle cases like s1 <-> s2 on netmerge to splitride into +i channel via KICK resolution like p10? messy...
  • Use ENCAP for more things (e.g. SVSQUIT, and so on) for better compatibility w/ native TS6, and less forced capabilities for server authors
    • SVSJOIN
    • SVSPART
    • SVSQUIT
    • SVSNICK (TODO also, should we split SVSNICK on nick collision into a SAVE extension?)
• review of vector use where list is sufficient
• blockcaps percentage setting, e.g. +B 95 for blocking 95% of caps per channel.. perhaps 5:93 type setting, 5 min chars, 93% to block..

Future (to be done at some currently undetermined point)

• (w00t for now?) Module to scan clients for open proxies (to complement m_dnsbl) (?). - someone who wants this can claim it
• Be able to override opertype fields for individual opers (e.g. host etc)
• (Brain) Less disgusting way to look up <connect> info (from user->MyClass, etc), than having to re-match just about everything in every module that wants to do it. Examples of where this is used: m_conn_umodes, m_ident
  • (more generally) Easier way to tie a config tag with a struct in memory, so e.g. modules can look up other details they add without having to go to a great deal of bollocks enumerating and matching stuff. an example would be storing a pointer to opertype & oper block config stuff in user class.

Being Considered....

These are ideas that we either like, (we just aren't sure when to do them), or ideas we aren't yet sure about.

• AWAY time notification: :AAAAAAAA AWAY 123456789 :away message here + send on whois optionally via new numeric
• XMLRPC stuff (ala atheme)?
• SQL logging of XLines Bug #357 (not a must now with xline db, according to owine)
• Bug #468 - add a return enum to mode parser so modules can determine what part of the parse failed
• Web configuration frontend
• Synching of channel ban details, this would require an entirely now BMASK or whatever command to sync bans, one per line (ick) Bug #420
• "Virtual hosts" - Server responds based on the dns entry used to connect to the server, different server names, auto joins, motd etc.
• Development/ChannelMembership Channel membership ideas
• Bug #521 - RMTKL/RMXLINE (done via third party, by Phoenix)
• Bug #528 - Restrict oper to particular login (done via third party, by Phoenix)
• Restriction of kills to local server (done via third party, by Om)