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
DarthGandalf (talk | contribs) No edit summary |
>Jpnurmi Rewrote the project structure section, and for now hid others that need rewriting |
||
| Line 1: | Line 1: | ||
= Random ideas = | |||
This page collects random ideas for the future versions of ZNC. Everyone is welcome to add their ideas on the list. Please tag each idea with your username. | |||
== Class and header file naming == | '''Disclaimer''': Some of the ideas are not going to be taken seriously, some are shot down right away, and some might even cause fuss and anger. Yet, please put emotions aside and try to be constructive with your [[{{TALKPAGENAME}}|comments]]. | ||
== Project structure ([[User:jpnurmi|jpnurmi]]) == | |||
Modularity and extensibility is admittely one of the key ingredients in ZNC's recipe for success. These days there is a ZNC module for pretty much any imaginable IRC task. Therefore modules deserve to be treated as first class citizens, with good care. ;) | |||
Related to versioning and compatibility as discussed below; since ZNC offers no stable module API and only does major feature releases, modules have somewhat high tendency to break on every ZNC version upgrade. This in turn makes such stakeholders as Linux distributions and ZNC hosting providers resistant to upgrade to the latest version. A stable module API would not only help module developers, but also anyone hosting a ZNC service. | |||
In order to achieve a stable module API, the ZNC core could be refactored so that the core types would be gradually moved to a separate library. It would be nice to make it a separate build unit to avoid undesired backwards dependencies to the ZNC application code. | |||
<pre> | |||
___________ ___________ | |||
/ ZNC app \ / ZNC lib \ ___________ | |||
| | | | / \ | |||
| - main() | --> | - CModule | <-- | ZNC modules | | |||
| - CModules | | - CString | \___________/ | |||
| - ... | | - ... | | |||
\___________/ \___________/ | |||
</pre> | |||
Notice that the library should be absolutely minimal. Most importantly, the public API should not contain anything ZNC application specific. That library would then eventually act as an interface for modules. This restructuring would greatly help maintaining a stable module API in the future, and thus make modules much less prone to break. ZNC would have full control over what modules have access to ie. modules would no longer be able to mess with ZNC internals that have no promise of API compatibility. | |||
[[User:Jpnurmi|J-P Nurmi]] ([[User talk:Jpnurmi|talk]]) 13:50, 7 March 2014 (CET) | |||
<!-- TODO: rewrite | |||
== Class and header file naming ([[User:jpnurmi|jpnurmi]]) == | |||
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: | 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, ... | * Z-prefixed non-abbreviated class names: ZBuffer, ZChannel, ZNetwork, ZString, ... | ||
| Line 9: | Line 35: | ||
* optionally, forwarding convenience headers: ZBuffer, ZChannel, ZNetwork, ZString... (no .h, includes the actual header) | * optionally, forwarding convenience headers: ZBuffer, ZChannel, ZNetwork, ZString... (no .h, includes the actual header) | ||
This way module developers would know exactly what to include. :) | This way module developers would know exactly what to include. :) | ||
~~~~ | |||
--> | |||
== Semantic "major.minor.patch" versioning == | <!-- TODO: rewrite | ||
== Semantic "major.minor.patch" versioning ([[User:jpnurmi|jpnurmi]]) == | |||
* major = major changes | * major = major changes | ||
* minor = new features | * minor = new features | ||
* patch = bug fixes only | * patch = bug fixes only | ||
See http://semver.org for more details. | See http://semver.org for more details. | ||
~~~~ | |||
--> | |||
== Binary/source compatibility ( | <!-- TODO: rewrite | ||
== Binary/source compatibility ([[User:jpnurmi|jpnurmi]]) == | |||
* a new major version allowed to be SC incompatible | * a new major version allowed to be SC incompatible | ||
** API changes, cleanup any deprecated stuff | ** API changes, cleanup any deprecated stuff | ||
| Line 26: | Line 58: | ||
** bug fixes only | ** bug fixes only | ||
** modules keep working without rebuilding | ** modules keep working without rebuilding | ||
~~~~ | |||
--> | |||
== Introduce a new (polymorphic?) "message" type == | <!-- TODO: rewrite | ||
== Introduce a new (polymorphic?) "message" type ([[User:jpnurmi|jpnurmi]]) == | |||
Instead of passing raw string lines/tokens around, a dedicated message class could offer a convenient API to access/modify message attributes: | Instead of passing raw string lines/tokens around, a dedicated message class could offer a convenient API to access/modify message attributes: | ||
* sender/prefix | * sender/prefix | ||
| Line 35: | Line 70: | ||
* timestamp | * timestamp | ||
* tags... | * tags... | ||
~~~~ | |||
--> | |||
<!-- TODO: rewrite | |||
== Coding conventions & style ([[User:jpnurmi|jpnurmi]]) == | |||
== Coding conventions & style == | |||
* pass value types by reference | * pass value types by reference | ||
* pass complex/polymorphic types as pointers | * pass complex/polymorphic types as pointers | ||
* ... | * ... | ||
* tabs to spaces :P | * tabs to spaces :P | ||
~~~~ | |||
--> | |||
Revision as of 12:50, 7 March 2014
Random ideas
This page collects random ideas for the future versions of ZNC. Everyone is welcome to add their ideas on the list. Please tag each idea with your username.
Disclaimer: Some of the ideas are not going to be taken seriously, some are shot down right away, and some might even cause fuss and anger. Yet, please put emotions aside and try to be constructive with your comments.
Project structure (jpnurmi)
Modularity and extensibility is admittely one of the key ingredients in ZNC's recipe for success. These days there is a ZNC module for pretty much any imaginable IRC task. Therefore modules deserve to be treated as first class citizens, with good care. ;)
Related to versioning and compatibility as discussed below; since ZNC offers no stable module API and only does major feature releases, modules have somewhat high tendency to break on every ZNC version upgrade. This in turn makes such stakeholders as Linux distributions and ZNC hosting providers resistant to upgrade to the latest version. A stable module API would not only help module developers, but also anyone hosting a ZNC service.
In order to achieve a stable module API, the ZNC core could be refactored so that the core types would be gradually moved to a separate library. It would be nice to make it a separate build unit to avoid undesired backwards dependencies to the ZNC application code.
___________ ___________ / ZNC app \ / ZNC lib \ ___________ | | | | / \ | - main() | --> | - CModule | <-- | ZNC modules | | - CModules | | - CString | \___________/ | - ... | | - ... | \___________/ \___________/
Notice that the library should be absolutely minimal. Most importantly, the public API should not contain anything ZNC application specific. That library would then eventually act as an interface for modules. This restructuring would greatly help maintaining a stable module API in the future, and thus make modules much less prone to break. ZNC would have full control over what modules have access to ie. modules would no longer be able to mess with ZNC internals that have no promise of API compatibility.
J-P Nurmi (talk) 13:50, 7 March 2014 (CET)