1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
|
# 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
|
