To create new wiki account, please join us on #znc at Libera.Chat and ask admins to create a wiki account for you. You can say thanks to spambots for this inconvenience.

Ideas: Difference between revisions

From ZNC
Jump to navigation Jump to search
>Jpnurmi
Initial draft
 
No edit summary
Line 1: Line 1:
This page collects random ideas for the next major version of ZNC.
This page collects random ideas for the next major version of ZNC.
= [[User:Jpnurmi]]'s ideas about how it should look like =


== Class and header file naming ==
== Class and header file naming ==

Revision as of 22:36, 6 March 2014

This page collects random ideas for the next major version of ZNC.

User:Jpnurmi's ideas about how it should look like

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:

  • sender/prefix
  • type
  • command/number
  • parameters
  • timestamp
  • tags...

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).

Project structure

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