Support for other protocols (gopher, spartan, ...)

[omar-polo]

In the past I've discarded the feature requests to add support for other protocols, since I saw gmid only as a gemini server. The idea was that if there was the need for a gmid-style server for spartan or gopher, a new server could be written (eventually borrowing from gmid.)

However this doesn't seem much viable practically speaking, and with also #19 there is some room to discuss adding other protocols to gmid. I'm fearing in part that we'd become a kitchen sink, but there is also some value in speaking a few adjacent protocols: the code won't explode in size and the service is nice.

This feature has to be planned carefully however. The protocol(s) implementation may be trivial, but the configuration changes have to be planned.

For example, gopher doesn't have (AFAIK) the notion of virtual hosts, so the server block makes little sense. On the other hand, stuff like the TLS settings makes sense only for gemini. On the third (?) hand, some options will need to be handled per-protocol (index comes to mind).

Titan (see #19) could also be "plugged" this way.

One way to handle this could be by introducing a protocol block. I still fear that we'd have to treat each protocol as it were a tiny snowflake in the configuration syntax anyway. We shouldn't be limited by the backward compatibility: at least initially let's try to design something that makes sense; we'll deal with the backward compat only when we have a nice design.

The milestone is temporary 2.2 (don't want to delay 2.1) but it could also be 3.0. Titan may be moved from 2.1 to this milestone.

Thoughts?

[omar-polo]

Another thing I forgot, should we also consider having multiple chroot? e.g. /var/gemini for the gemini content, /var/gopher for gopher and so on...?

[ThomasAdam]

Hi,

I agree with this overall sentiment. It's important to remember that gmid right now only understands gemini.

If we were to introduce other protocols -- the most practical example right now is gopher -- this has very different requirements compared to gemini, compared to $SOME_OTHER_PROTOCOL. As a result, I feel we need to protect those things from a server-perspective which are also going to be common to whichever protocol.

For example, you could say (I'm surmising on the syntax here -- I'm not wanting to bikeshed this at all just yet. This is for illustrative-purposes only):

server {
    protocol "gopher"
    domain "gopher.example.org"
    port 71
    root "/var/something/gopher"
    index "gophermap"
{

In this example, there is a server block, where the protocol is gopher, and the rest follows.

Similarly, one could imagine:

server {
    protocol "gemini"
    domain "gemini.example.org"
}

I'm refraining from adding any "metadata" to the server name, so as to infer everything it needs.

Note that, in this way, with a server block defined, we could infer missing attiributes. For example, if there were a server block without a port attribute, but the protocol were gemini, we should infer port of 1965.

I don't think this assumption is unreasonable. That's how a lot of configs work.

With regards to becoming a kitchen sink, I doubt that. At the very least, gemini, and gopher are sufficiently close enough that this analogy makes sense.

Were we to introduce another type, it's possible we could add a proxy variable with a hostname:port requirement to infer serving up "unknown" content.

But the key thing here is that gmid has enough latitude right now to support different protocols, and that's what I intend to do.

Note that there's a fair amount of refactoring work I can do as an almost prerequisite to any thing else proposed here. That's precisely what I intend to do.

[omar-polo]

Note that, in this way, with a server block defined, we could infer missing attiributes. For example, if there were a server block without a port attribute, but the protocol were gemini, we should infer port of 1965.

I don't think this assumption is unreasonable. That's how a lot of configs work.

I think this is very reasonable.

With regards to becoming a kitchen sink, I doubt that. At the very least, gemini, and gopher are sufficiently close enough that this analogy makes sense.

Yes, I agree, otherwise I wouldn't have created this issue to discuss :)

That was the past me worrying, but I've changed my mind and pragmatically speaking I believe it's fine to make this move. I just need to slightly change the topic for gmid from "gemini server" to "smol internet server" or something like this.

I'm not wanting to bikeshed this at all just yet. This is for illustrative-purposes only

instead I'd like to bikeshed this a bit! :P

Or, phrasing it better, to brainstorm a possible grammar. I was thinking of something around these lines:

protocol gopher {
	listen on localhost # implicit "port 71" for gopher!
	root /some/path
	chroot "/var/gopher" # different chroot path for gopher?
	prefork 2 # different prefork for gopher?
	auto index off # maybe even different defaults per-protocol?
}

protocol gemini {
	chroot "/var/gemini"
	prefork 5

	server "example.org" {
		listen on localhost # implicit "port 1965"
		cert "/path/to/cert"
		key "/path/to/key"
		root "/some/other/path"
	}
}

[ThomasAdam]

That was the past me worrying, but I've changed my mind and pragmatically speaking I believe it's fine to make this move. I just need to slightly change the topic for gmid from "gemini server" to "smol internet server" or something like this.

Right... yeah. I think this likely what I see gmid becoming. Albeit, there's only a handful of protocols I can think of right now that gmid could possibly end up supporting.

Or, phrasing it better, to brainstorm a possible grammar. I was thinking of something around these lines:

protocol gopher {
	listen on localhost # implicit "port 71" for gopher!
	root /some/path
	chroot "/var/gopher" # different chroot path for gopher?
	prefork 2 # different prefork for gopher?
	auto index off # maybe even different defaults per-protocol?
}

OK, that's interesting. Rather than having multiple server blocks as a top-level container, you're proposing grouping these by protocol. Hmm, I think I like this idea much more than mine -- it also means for things like gemini (as you've suggested in your example), you can have multiple server blocks.

I think this looks good to me!

[omar-polo]

Great, I'm happy that you like the current status of the proposal. (i said to not care about backward compatibility at this stage, but we could assume an implicit protocol gemini if no protocol block is found to support existing configurations without changes :P.)

Do we want to support per-protocol chroot and prefork settings? If so, each protocol will need to have its own set of "server" processes. it could also be interesting to split each protocol handler in its own libexec executable, so that for e.g. we don't have to link the gopher libexec with libtls.

[ThomasAdam]

Great, I'm happy that you like the current status of the proposal. (i said to not care about backward compatibility at this stage, but we could assume an implicit protocol gemini if no protocol block is found to support existing configurations without changes :P.)

Yeah, that makes sense.

Do we want to support per-protocol chroot and prefork settings? If so, each protocol will need to have its own set of "server" processes. it could also be interesting to split each protocol handler in its own libexec executable, so that for e.g. we don't have to link the gopher libexec with libtls.

Yes -- exactly that. Perhaps that didn't come across well enough in my last reply, but doing this would make it easier for libexec helpers which makes sense.

[omar-polo]

Perfect, so we're on the same page on this. proc.c will need some rework but I don't mind it.