diff options
Diffstat (limited to 'TODOs.md')
| -rw-r--r-- | TODOs.md | 137 |
1 files changed, 0 insertions, 137 deletions
diff --git a/TODOs.md b/TODOs.md deleted file mode 100644 index 368c6cf..0000000 --- a/TODOs.md +++ /dev/null @@ -1,137 +0,0 @@ -# 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 |