Struct names and members for secrets.conf
Julien ÉLIE
julien at trigofacile.com
Thu Dec 23 22:51:07 UTC 2021
Hi all,
For the new secrets.conf file, we spoke about the following contents:
cancels {
canlockadminsec: [ "password" ]
canlockusersec: [ "anotherpassword" ]
}
I've created lib/secretsconf.c and include/inn/secretsconf.h (not yet
committed) to handle the creation of the new struct for our secrets.
When using secretsconf->canlockadminsec to access it, I'm wondering
whether it should not just be:
cancels {
canlockadmin: [ "password" ]
canlockuser: [ "anotherpassword" ]
}
and we just call secretsconf->canlockadmin.
When we have dozens of secrets in secrets.conf, it will be weird to
always add "sec" in the parameter name, won't it?
To parse secrets.conf, I just search the "cancels" tag and get the
values from it. It works fine but will need changing when other secrets
are added in the future.
/* INN_PATH_SECRETS is "secrets.conf" in paths.h */
configfile = concatpath(innconf->pathetc, INN_PATH_SECRETS);
group = config_parse_file(path == NULL ? configfile : path);
free(configfile);
if (group != NULL)
subgroup = config_find_group(group, "cancels");
/* Unconditionally parse subgroup, even if NULL, in order
* to initialize vectors. */
secretsconf = secretsconf_parse(subgroup);
if (group != NULL)
config_free(group);
That's why it populates secretsconf->canlockadmin(sec).
Would it be better to have instead:
- secretsconf->cancels->canlockadmin
- cancels->canlockadmin
- cancels_secrets->canlockadmin
?
Maybe the first (secretsconf->cancels->canlockadmin) is better but we
may also create as many simpler structs as group types in secrets.conf.
Just asking in case you have a preference or another better idea.
With the first proposal, I'll probably have to add a
secretsconf_get_cancels() function to retrieve the cancels groups in the
secretsconf struct (and then use the result as if it were one of the
last 2 proposals in fact).
If we have something like that in the future in secrets.conf:
feed news.server.com {
login: "login"
password : "pass"
}
feed news.server2.com {
login: "login2"
password : "pass2"
}
We would have secretsconf->feed being a chained list of structs:
struct feed {
char *tag;
char *login;
char *password;
struct feed *next; /* next would be for "news.server2.com" tag */
};
(assuming we don't use nested groups inside them).
Maybe secretsconf->cancels (or whatever name) should also be constructed
this way (a chained list of structs)?
struct cancels {
char *tag; /* NULL */
struct vector *canlockadmin;
struct vector *canlockuser;
struct cancels *next; /* always NULL though */
};
Though I would be inclined not to have "tag" and "next".
Apart from that detail to finalize the patch, Cancel-Lock generation
works fine!
--
Julien ÉLIE
« Et vous allez reprendre votre bateau… Et, mergitur ou pas, fluctuat !
Compris ! Fluctuat ! » (Goudurix)
More information about the inn-workers
mailing list