# Tasks # Bugs # Improvements # Questions ## TODO wxWidgets nativeness {#td-d27aca11-9449-bb0e-08cb-2a8ef9778a11} - TODO in 2023-11-10 --- With enough care, can a wxWidgets application become polished enough to make dedicated GTK and Qt applications unnecessary? poedit(1) is the only app I can think from memory that is written in wxWidgets. I should look for more apps and benchmark them on different platforms. # Decisions ## TODO Accepted dependencies {#td-faf15e3f-4a57-a99e-55c6-53ffd7448962} - TODO in 2023-11-09 --- - Node.js: for running the application; - SQLite: for storing data for history, queues and auth; - maybe some library with Node.js binding to SQLite. Since the fancy chat is going to be done first (see [#td-ed5d15f4-ec30-7411-fa74-552a06569c91](#td-ed5d15f4-ec30-7411-fa74-552a06569c91)), it may be possible to postpone the SASL authentication and rely only on the `NickServ` authentication for now. ## TODO IRCv3+ first, RFC 1459 after {#td-ed5d15f4-ec30-7411-fa74-552a06569c91} - TODO in 2023-11-09 --- Do the fancy chat first, and the basic one after. ## TODO Encubate dependencies than move them out {#td-1045dbb9-fd89-e254-3e9d-642cb112c6ad} - DONE in 2023-11-09 --- In order to achieve the reliability and robustness targets I have, and to build something that I'd want to personally use deploy, I'll need as few dependencies as possible. So as papo gets built, I'll need miniscule libraries for web routing, WebSockets, etc., and as I write those inside papo itself, I'll eventually pull them out as standalone dependencies. So the apparent number of dependencies may seem to grow, but only because they're being separated from papo itself, so that this repository contains code relating to chat things, and infrastructure things go to their own repository. Also despite the apparent dependency count growth, these dependencies are being bu8ild alongisde papo and with its robustness, reliability and correctness standard from the beginning, so the mismatch in quality is not a concern. ## DONE Assume Node.js {#td-faae1d8e-4015-cb78-0fe9-d003428266c9} - DONE in 2023-11-09 --- Despite existing multiple available JavaScript runtimes these days besides Node.js, like Deno (also V8), QuickJS, Bun, Hermes, etc., I'll stick to Node.js, for a few reasons: - it allows me to focus on getting things out there by leveraging Node.js-specific functionalities; - it prevents me from wasting time writing compat layers for the multiple implementations. If a compatibility API across runtimes ever emerges I'll adopt that, but untill then I'm better off getting things done rather than supporting as many platforms as possible when I need not to. Its better for me to use this time and energy improving papo itself. # Resources ## Relevant links On May 23, 2014, from https://news.ycombinator.com/item?id=7790847: > (...) Checking code into a directory managed by npm is simply asinine, and > putting symlinks in there is just as "coupled to the runtime environment > configuration" as the NODE_PATH solution. What is really needed is a > reasonable (and supported) method of programmatically managing the node search > path. > > Why the node community is so stubborn about this point is a mystery to me and > it makes me wary of node in general, because who wants to be locked into an > environment where such an obvious pain point is ignored due to stubbornness? On March 3, 2021, from https://drewdevault.com/2021/03/03/To-make-money-in-FOSS-build-a-business.html: > I’ve often said that you can make money in FOSS, but not usually by accident. > Don’t just build your project and wait for the big bucks to start rolling in. > You need to take the business-building seriously from the start. What is the > organization of your company? Who will you work with? What kind of clients > or customers will you court? Do you know how to reach them? How much they’re > willing to pay? What you will sell? Do you have a budget? If you want to > make money from your project, sit down and answer these questions seriously. > > Different kinds of software projects make money in different ways. Some > projects with enterprise-oriented software may be able to sell support > contracts. Some can sell consultants to work on integration and feature > development. Maybe you can write books about your software, or teach courses > on it. Perhaps your software, like the kind my company builds, is well-suited > to being sold as a service. Some projects simply solicit donations, but this > is the most difficult approach. on March 29, 2022, from https://news.ycombinator.com/item?id=30842507: > That's not an argument for sticking with the old programming language that > apparently is impossible to use safely (if you think that you can use it > safely, what makes you think that you are better than the all-star cast of C > programmers that have contributed CVEs over the years?). There were better > alternatives to C in the 80s, there most certainly are better alternatives to > C these days. I'm so sick of the Uncle Bob school of thought that all that is > needed for better software engineering is discipline. If we haven't managed to > impose that discipline yet after five decades, why would we believe that it > will magically appear in the future? My guess is that a programmer that had > the requisite mythical discipline would gravitate to programming languages > like Rust or Ada anyway, because that developer wouldn't mind tooling that > helped with it. # Scratch