Soon after Test::Async time has came for the first release of Config::BINDish. At first, I didn’t plan the module whatsoever. Then I considered it as a little distraction project to get some rest from an in-house one I was working on lately. But it turned into a kind of a monster which swallowed quite an amount of my time. Now I hope it’s been worth the efforts.

Basically, the last straw which convinced me to eventually put everything else aside and have this one done was an attempt to develop a model for scalable file hosting. I was stuck, no approach I was considering was good enough. And I decided to change the point of view and try to express the thing in terms of a configuration file. I went on a hunt onto Raku modules site and came back with a couple of already familiar options. Of those I decided that Config::TOML would be the best one for my needs. Unfortunately, very soon I realized that a feature it misses makes my life somewhat harder than I’d like it to be: there was no way to expand a string with an option value.

Aside of that, I found myself almost unconsciously writing something like this to describe the case:

file-pool "public" {
    server-url https://s1.local;
    path ...;
}

And so on…

A few weeks later I eventually can have this in my config:

default-server "A1";
server "A1" {
    url "https://a1.local";
}
server "A2" {
    url "https://a2.local"
}
network "Office" {
    api-url "{/server("{/default-server}")}/api"; # https://a1.local/api
    subnet 192.168.1.0/24;
    default-gw 192.168.1.1;
    ns { 192.168.1.1; 192.168.1.5 }
}

Yes, it’s not exactly the way they have it BIND9. That’s why I call it BINDish. But with a few tweaks it should be possible to parse named configs too would one ever need it.

And for me it’s time to spend a week or two on a road and then – back into the business!

Comments