1. 19
  1.  

  2. 6

    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.)

    1. 5

      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.

      1. 4

        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.

        1. 1

          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.)

        2. 6

          Crypt egg author here; what exactly did you run into when installing it?

          1. 4

            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.

            1. 8

              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 :)

          2. 3

            I’m interested but… are there screenshots? Docs on how to actually use it?

            1. 3

              I updated the README with more “how to use” documentation, including a web server configuration snippet I am using.

              There are no screenshots yet.

            2. 2

              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.

              1. 3

                My blog still uses Blosxom, but I’m generating the pages statically.

                1. 2

                  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.

                2. 2

                  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 :)

                  1. 1

                    Thanks. I added a sales pitch to the README.

                  2. 2

                    @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)

                    1. 1

                      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.