Talk:Ideas

Uli's complaints (TODO: Better headline)

• The big rename (ZFoo): I never saw a project were this was a good idea. Of course I won't stop anyone to do this, but I won't encourage anyone either.
  • There's the initial hurdle, but in the end module developers will be happier with a beautiful and consistent API to develop with. J-P Nurmi (talk) 17:41, 6 March 2014 (CET)
    • namespace znc --DarthGandalf (talk) 22:20, 6 March 2014 (CET)
      • sure, that works as well. my proposal was based on qt-style naming, but in the end all that matters is consistency and beauty. :) avoid abbreviations and redundancy in the names, ensure exact mapping between public class names and corresponding header file names etc. J-P Nurmi (talk) 22:52, 6 March 2014 (CET)
• Semantic versions: So the only difference to right now is that we get another .0 at the end of the version number? ZNC had a grand total of two bug fix releases in its history (I think) and those were for CVEs...
  • Release early, release often. I'm sure your customers would appreciate. ;) Branching and semantic versioning in a nutshell; master branch for new features, X.Y branch for bug fixes (periodically merged to master). Bugfix releases tagged from X.Y branch, master forms the next X.Y.0 release (and eventually the next X.0). J-P Nurmi (talk) 17:41, 6 March 2014 (CET)
• Binary compatibility: Just not possible. Basically every release would be a major release. Feel free to convince me otherwise, but "binary compatible" and "C++" mostly means "don't change anything".
  • My suggestion is to keep it simple and provide binary compatibility only for bugfix releases. New feature development happens in master, not in the X.Y branch where bugfix releases come from. Even for master, my suggestion would be to keep old deprecated methods and types around instead of breaking source compatibility. J-P Nurmi (talk) 17:41, 6 March 2014 (CET)
• Message type: Since we don't promise API stability anyway, this can happen outside of ZNCv2 (aka "can be done right now, too")
  • I'd like to kindly ask you to reconsider. ZNC has such a nice bunch of official and unofficial modules, it would be a pity to break them like that. Any module written for the 1.x series would ideally work with later 1.x releases. Write such intrusive ideas down or as TODO comments in the code. Once you have a reasonable set of changes in mind, start preparing for the next major release. Module developers know that something needs to be updated in order to support the new major version. If the changes are beneficial, module developers will surely follow. J-P Nurmi (talk) 17:41, 6 March 2014 (CET)
• Radically reduce the amount of module hooks: "Radically" means "4"? Also, what's the point? Most modules will check for the type of message as first thing anyway and e.g. immediately return for queries. So this just makes modules more complicated
  • Sorry, I'm not familiar enough with the CModule API to understand which hook does what, but my first impression was - please make it simpler. :) Perhaps it would be easier to understand if the module API was structured after the categories? Furthermore, ideally the interface for ZNC app wouldn't be exposed for module developers. J-P Nurmi (talk) 17:41, 6 March 2014 (CET)
    • No idea how to do categories in doxygen, but our message-related module hooks right now would be: Coming from the user: CTCP replies, CTCPs, Actions (which is just a special kind of CTCP and could be removed, but then again CTCPs are just special kinds of notices/messages, so that doesn't really work), messages and notices; Coming from IRC: The same times two. We have the flavors for "goes to channel" and "just goes to me". All of them are useful and a lot of them could be dropped, but doing so would make modules uglier. After all, we only really need OnUserRaw() and OnRaw() (gets "raw" lines as received from the user/server) and modules could parse the messages themselves. Not really nice.... Psychon (talk) 18:31, 6 March 2014 (CET)
      • Perhaps dividing the monolithic CModule into smaller entities would help? For instance, CModule could act as a mere module descriptor. The hooks could be grouped to a bunch of interfaces that one can implement depending on the module type. J-P Nurmi (talk) 23:47, 6 March 2014 (CET)
• Project structure: Are you saying that modules must not link against symbols from the znc binary? We already have a libznc.dll for cygwin. It contains everything but main(). There just is no sane way to split things up currently, but feel free to proof me wrong.
  • The library is the part that we would retain backwards compatibility for. On the app side you may do anything you want since that wouldn't break modules. Modules shouldn't have access to application specific code. J-P Nurmi (talk) 17:41, 6 March 2014 (CET)
    • That's the problem. Right now I can't think of a single class in ZNC which shouldn't be used by modules, but only by "the app". This means everything is API and things go downhill. Psychon (talk) 18:31, 6 March 2014 (CET)
      • Yeah, the division is not _that_ simple. Looking at Modules.h alone, it contains stuff that is presumably not supposed to use by module developers. I can't think of a reason for a module developer to use such things as CModule::SetUser(), SetNetwork(), SetClient(), and the whole CModules collection. In order to achieve a nice API for modules, we need to think from their perspective, not what ZNC itself needs to controls things. J-P Nurmi (talk) 18:59, 6 March 2014 (CET)
• Coding style: Hahaha. No.
  • Are you laughing at all the points or some specific of them? Regarding passing certain types always by reference or as pointers... alongside good naming, consistency is one of the most important factors for easy to memorize APIs. J-P Nurmi (talk) 17:41, 6 March 2014 (CET)
    • Indentation by spaces: Nope; Passing ints around by reference: This even has negative runtime impacts; Complex types by pointer: Nah, currently we (mostly) have the semantics "a pointer can be NULL, use a reference if it's never NULL".
      • A) So tabs, fair enough. I couldn't resist to propose spaces since tabs makes the indentation mess, especially now that it's mixed with spaces. It's not only about your own personal editor where you can configure the tab width, but various tools and sites where you can't. B) What comes to passing value types by reference, I didn't mean primitive types, but strings, containers etc. I think this is already done all over the ZNC codebase, but I just wanted to make a distinction to the complex types that I would prefer to pass as pointers. C) Now that complex types are handled as a mixture of references and pointers, the downside is that one often ends up wondering whether this and that method takes a pointer or a reference. Furthermore, constantly taking addresses of references and dereferencing pointers just to pass them further is IMHO not pretty. J-P Nurmi (talk) 18:59, 6 March 2014 (CET)

Psychon (talk) 16:37, 6 March 2014 (CET)