This page collects random ideas for the next major version of ZNC.
Class and header file naming
Currently, class names are C-prefixed (eg. CBuffer) and some have an additional IRC-prefix (eg. CIRCNetwork). Header file names don't have the C-prefix, but some have a ZNC-prefix (eg. ZNCString.h) to avoid name clashes. It would be nice to have consistent and predictable names, so I'd like to propose the following convention:
- Z-prefixed non-abbreviated class names: ZBuffer, ZChannel, ZNetwork, ZString, ...
- lower-case header files that follow class names: zbuffer.h, zchannel.h, znetwork.h, zstring.h, ...
- optionally, forwarding convenience headers: ZBuffer, ZChannel, ZNetwork, ZString... (no .h, includes the actual header)
This way module developers would know exactly what to include. :)
Semantic "major.minor.patch" versioning
- major = major changes
- minor = new features
- patch = bug fixes only
See http://semver.org for more details.
Binary/source compatibility (with semantic versioning)
- a new major version allowed to be SC incompatible
- API changes, cleanup any deprecated stuff
- modules need to be updated
- a new minor version allowed to be BC incompatible
- may introduce new methods & overloads, keep but deprecate old ones
- modules need to be rebuilt
- a new patch version should be BC/SC compatible
- bug fixes only
- modules keep working without rebuilding
Introduce a new (polymorphic?) "message" type
Instead of passing raw string lines/tokens around, a dedicated message class could offer a convenient API to access/modify message attributes:
Radically reduce the amount of module hooks
This would go hand in hand with the new message type. Basically, have something like OnMessage(msg) instead of OnThis(chan,str,str) and OnThat(nick,str).
Split the ZNC app out of the core:
- core (lib)
- znc app (links to core)
- modules (link to core)
Coding conventions & style
- pass value types by reference
- pass complex/polymorphic types as pointers
- tabs to spaces :P