💾 Archived View for gemini.susa.net › gemini_and_http.gmi captured on 2021-11-30 at 19:37:34. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Gemini has no dependence on HTTP - most Internet protocols are independent like that (exceptions are HTTPS and SFTP, I suppose), but I'm going to argue that there's a relationship, just like with all the other protocols. For example, HTTP carries links to RTSP, SMTP carries links to HTTP, SSH runs my shell that lets me edit this page.
To be clear, I was looking for Gemini since before it was invented. My foray with Gopher ended when a bargain-basement VPS provider accidentally wiped their disk (hardware failure, I think). I had no backup, and Gopher was just a little bit too archiaic for me to re-invest time in.
Gemini's different. The immediacy of everything Gemini is the reason I'm writing these words in plain text with 'vi'. I don't need to know or remember anything much to get text online - no markup, no doctype, no boilerplate, no layout. I literally get a sense of catharsis as I write this - there's a low ratio of complexity to content, unlike the web where complexity is expanding like Hubble's universe (and content is arguably diminishing). I have no objection to complexity, as long as there are benefits in return.
Yet the essence of HTTP is great. It has solved a lot of interesting problems, it's well documented, and it has vast amounts of good software available for it. It doesn't have, and never will have, the simplicity of immediacy of Gemini. It has an entirely different use-case.
I really don't know. There's nothing substantial that's made me want HTTP from within Gemini - perhaps an ability to process input from a form. Interestingly, from my own content, currently 8 links out of 92 are to HTTP resources. Lower than I thought, but no entirely insignificant.
Here are a few ways I envisage HTTP might work in tandem with Gemini: -
What I really want to avoid is managing a complex web server. I don't want to risk the server being exploited due to misconfiguration, I don't want a huge memory footprint for features. What I probably do want is the world's first web server with a small handful of enhancements (e.g. byte-ranges are nice and efficient, authentication driven by my Gemini server e.g. token).
At the other end of the wire (or fibre), I don't want to use a heavy browser. There are excellent lightweight browsers such as Lynx, Dillo - I'm sure I spotted some HTTP support in Kristall.
However, as I write this, the strongest driver in my mind is to shield Gemini from feature-creep. We're all going to have our own needs that are not currently met by the Gemini Specification. There will be pressure to make changes (a character trait of many of us is dogged determination(!)), and being able to push demands towards a more suitable protocol might satisfy the drive to create stuff without polluting the Gemini protocol.
I'm currently looking at lighttpd as an option, to run on port 1993. It's running with 5MB resident RAM (impressive), but has a huge configuration footprint - modules for lots of stuff - ideally I'd want to get this down to IP/port to bind to, webroot directories, and virtual host configuration.
I don't expect to progress much, unless I actually find myself with a need for anything HTTP within geminispace. Regardless, here are some notes on my companion HTTP server configuration.
TinyHTTPD turned out to have a large memory footprint (100MB+), because it uses mmap to map files directly into the address space. The performance this gives is not worth the memory cost for a niche like Gemini.
Lighttpd seems to run at around 5MB resident memory, so I've focusd on that for now (I can't help thinking this is still overkill for the use-case, but easily workable).
./configure --with-openssl --without-{sqlite,uuid,pcre,bzip2} # I'll avoid an install, so make a runtime directory mkdir gemini/http # move the binaries into the runtime mv src/lighttpd src/.libs/ gemini/http # My stanza to restart the server (from within gemini/http) pkill lighttpd; sleep 1; ./lighttpd -f ./lighttpd.conf -m .libs/ # Test with links, ignore cert verification links -ssl.certificates 0 https://gemini.susa.net:1993 vi ~/.links2/links.cfg # Put 'ssl.certificates 0' in here if wanted. # See the memory usage of lighttpd ps ax -F|egrep 'UID|http' # My current file listing, note 'mime.conf' came from doc/config/conf.d/ in # the original lighttpd tarball that I used to build from. kevin@kakapo:~/gemini/http$ ls -l total 1316 -rw-r--r-- 1 kevin kevin 164 Aug 12 21:02 error.log drwxr-xr-x 3 kevin kevin 4096 Aug 12 20:46 htdocs -rwxr-xr-x 1 kevin kevin 1286176 Aug 12 20:11 lighttpd -rw-r--r-- 1 kevin kevin 11180 Aug 12 21:02 lighttpd.conf drwxr-xr-x 2 kevin kevin 4096 Aug 12 20:11 lighttpd_libs -rw-r--r-- 1 kevin kevin 6 Aug 12 21:02 lighttpd.pid -rwxr-xr-x 1 kevin kevin 2190 Aug 12 20:28 manpage_lighttpd -rw-r--r-- 1 kevin kevin 21950 Aug 12 00:22 mime.conf
My current 'lighttpd.conf' file looks like this as follows, though it's only been naively hacked up. Needs further consideration!
kevin@kakapo:~/gemini/http$ grep -v '^#' lighttpd.conf |grep -v '^