I'm genuinely curious.. when I make #FOSS applications I always make it work according to my needs instead of thinking about making it usable for everyone else. Is this normal? Am I the only one who does this? #oss
@ro I try making my stuff portable but often streamline for my own use-case with the plumbing in place to streamline for others if the need actually arises.
My previous web framework for example had a mechanism to generate configs for easier deployments, but I only implemented it for nginx+uwsgi because that's what I was using.
@ro Eh, if it's geared towards your personal use-case anyways, I'd say just don't package and release it as a… crate I think is the term in rust?
If you wanna be super clear about this, you can just add a README with a note about what use case it actually works in or it not being for public consumption or whatever.
That way people can find it and use your code to possibly find a solution to their specific problems but it's clear that it's not a supported package.
Okay, after doing a couple hours of research I'll still want to use uwsgi to deploy the new site, even tho the project marked itself as "in maintenance mode".
Reason being that I need to pass info about client-cert auth to the web application but I don't want to pass it in via header because it's security-critical.
Doing it with headers would of course work, but then commenting out a line of the nginx config would lead to a silent-ish failure where clients can sidestep the entire cert auth by just sending the right headers and that seems like a bad idea – so I want to keep that info out-of-band.
That's what you can do with uwsgi_param – or fcgi_param and scgi_param for that matter.
There is support for (ha)proxy protocol in both nginx and Gunicorn to pass out-of-band information, but it has a pre-defined list of fields and while those seem to include whether the client cert auth passed, there's no field for the cert or its fingerprint, which I need to check which user the the cert is assigned to.
So, wrapping WSGI in FCGI or SCGI would feasibly be an option but the most popular project there – flup – is so old that even it's "new" python 3 port (flup6) is already so old that the repo isn't reachable and the last update was in 2015.
Apart from that, there only seem to be wrapper projects with like 5½ commits and a bus factor of "author might have already been swallowed by the earth". :thaenkin:
Tons of work (SVG 2, fill & stroke, and more) has sat unimplemented for years. At this point, in standards circles, we know not to touch SVG with a barge pole.
@leaverou I'm somebody who puts a focus on JS-less web development and I not only create SVG assets with Inkscape but also write SVG myself, both static and templated and I think it's the same reason why HTML didn't see any big developments in over 2 decades…
Google has a controlling interest on the web and Google wants everything to depend on JS because that's what their data collection (i.e. profits) are based on.
