[experiment] caddyfile block type experimnet

[elee1766]

an experiment to see how registering and this plugin would work with caddyserver/caddy#7344

so a caddyfile could look like this

{
	admin off
	log {
		level DEBUG
	}
}

[l4.server] :5000 {
	route {
		echo
	}
}

[l4.server] :5001 {
	route {
		echo
	}
}

[elee1766]

the ci doesn't build because the replace directive/go.mod doesnt seem to get used for the actual ci build i guess?

[mholt]

Ohhhh this is actually pretty cool.

The CI is failing due to a lint error, regarding import formatting/order.

[elee1766]

i fixed that lint error, but still have the same lint error as master.

[elee1766]

so i think i kept it fully backwards compatible with the global block, in the way that even you can have both?

[vnxme]

Hi! Do we expect other layer4 block types? I mean this PR suggests [l4.server] indication should be used, which I read as server entity under l4 group. If no other layer4 block types are expected (at least I can't suggest any), what if we simplify the indication to [layer4] or even [l4]?

{
	admin off
	log {
		level DEBUG
	}
}

[layer4] :5000 {
	route {
		echo
	}
}

[layer4] :5001 {
	route {
		echo
	}
}

[elee1766]

@vnxme

it may be wanted to put global configuration for the layer4 module in a [layer4] block instead of [global] block. this was my thought.

to me that makes more sense. (plugins should declare their own block to configure their plugin, not inject into global directive)

altho ultimately I think it will come down to what is decided for http, if it is [http] or [http.server] for blocks

[vnxme]

@elee1766, it makes sense, thanks.

By the way, it would be much more informative and let me (and probably others) save time, if you could name your commits in a more elaborate way. You know, commits with "noot", "no idea", etc. don't contribute to understanding what you've done. Though what you're proposing to merge seems to be really valuable.

[elee1766]

@vnxme hi. i commit files just to save progress so i can revert for my own work, so there are no messages. they are not meant to be read or contain any context.

if you dont want the eyesore on github, i could just not push and squash my commits before i push. (but here they are squashed for merge anyways)

usually i try to provide enough context in the PR body, to give context for code changes, but this is still a draft, so i have not written it yet.