CGI has pretty terrible performance since it launches a process per HTTP request. That’s a common reason for people’s blogs to keel over when slashdotted. Do you have plans to adopt a faster API? (Theres FastCGI, but I think often people just build a little HTTP server into their blog engine and then proxy their main server to it.)
For a blog, there’s no reason you can’t just cache heavily. Your server can absolutely handle a few hundred cgi requests per minute.
I’m undecided on that point. I may end up doing some static generation in the background / under the hood, where the static pages are essentially just a pre-rendered cache. For now, CGI is a pleasure for prototyping. Just move the new thing to /cgi-bin; there’s no need to restart a service etc. when something changes.
The output from this program is highly cachable; the only time it is going to change is on a database update.
It’s definitely not ideal. fork/exec takes about 1-2ms for an AOT compiled program with a small runtime. You should expect to be able to get something like 10-100 reqs/s per core with CGI: I see about 100-150 req/s for some trivial C cgi script on my dinky laptop with XAMPP.
Historically it was worse for Perl, Python, etc partly because requires/imports/includes in dynlangs were typically awfully slow. (Still are for most, dunno if state of the art moved on.)
Crypt egg author here; what exactly did you run into when installing it?
A musl problem, it seems. Apparently musl doesn’t exec the shebangless build-crypt.sh.
Here is a typescript file of a failed build and here is a patch.
I also turned up a musl issue in the stty egg. That one is going to take a bit more effort, I think.
BTW, I assume you’re the same person who wrote the xml-rpc egg for Chicken 4. If so, would you be interested in a port of that to Chicken 5? I’ve been working on one.
Thanks, I’ve patched and released 1.0.1 which should be available soonish (when our release scraper comes across it).
Yes, I’m the author of the XML-RPC egg as well. I would of course accept a patch to port XML-RPC to C5, but I’m not using it anymore, so if you’d like to take over maintainership that would be even more excellent :)
I’m interested but… are there screenshots? Docs on how to actually use it?
I updated the README with more “how to use” documentation, including a web server configuration snippet I am using.
There are no screenshots yet.
I’m a sucker for “minimal”. Reminds me of Blosxom, a beautifully minimal weblog system based on files rather than any RDBMS, which I used in the early 2000’s (here’s a post from then, although the links are all broken now, sadly). Talking of that era, I was struck by the reference here to XML-RPC as the possible API base for this engine. XML-RPC was very much en vogue around that time too; the fledgling blogosphere was quite small and connected then, and Rael (Blosxom), Dave (XML-RPC) were part of that group.
My blog still uses Blosxom, but I’m generating the pages statically.
Blosxom was one of my inspirations. I used a fork (pyblosxom) for very many years.
Rael Dornfest, Dave Winer, et al, were really onto something.
Seems cool! Not sure why I’d use it in place of WordPress, but a very cool project that seems really approachable. I look forward to seeing more docs and examples, if that’s in the pipeline! Good luck :)
Thanks. I added a sales pitch to the README.
@teiresias To me ‘This isn’t X’ in software projects often signifies ‘This is actually quite a lot like X’.. or 50% compatible or something. Is it just a cool name, ir are you planning to make anything that’s compatible with the existing WP world? (the WP ‘API’ being huge and awful)
It’s just a cool, silly name that happens to be a tautology. If I implement any WP compatibility, it will be the XML-RPC API, in part or in whole. Likely I’d implement just enough to be able to use existing CLI or emacs-based WP posting tools.