RFC: Multidomain: Primary vs. Pretty domain names

[mweinelt]

Currently with multidomain builds all domain names within a domain are treated equally and only the one selected is announced, even though that is most likely just be a pretty name. We however do need the technical domain name to be able to link them logically to our gateways, who simply cannot announce themselves as part of all the possible pretty domain codes.

In practice that means that in tools like meshviewer we have the multiple domain codes (pretty and logical) for a single L2 domain. Consider the following configuration:

        domain_names = {
                dom1 = 'Domain 1',
                ffda_da_110 = 'Darmstadt: Stadtzentrum',
                ffda_da_120 = 'Darmstadt: Mollerstadt',
                ffda_da_130 = 'Darmstadt: Hochschulviertel',
                ffda_da_210 = 'Darmstadt: Johannesviertel',
                ffda_da_220_230 = 'Darmstadt: Martinsviertel',
                ffda_da_270 = 'Darmstadt: Bürgerparkviertel',
                ffda_da_310 = 'Darmstadt: Am Oberfeld',
                ffda_da_320 = 'Darmstadt: Mathildenhöhe'
        },
        hide_domains = { 'dom1' },

Multiple nodes will happily announce all of the above. But gateways can only be part of one of these.

In my opinion we need to clean up the meaning of the domain_code variable to be more technically helpful. Any way I can imagine would require some migration strategy, that I have no clear idea of yet.

I'd imagine the following would be a more proper configuration structure for what is actually being required:

        domain_name = "dom1",  -- this is the logical domain name, that is used for configuration and for the respondd domain_code
        domain_pretty_names = {
                -- these are the names being offered in the dropdown
                ffda_da_110 = 'Darmstadt: Stadtzentrum',
                ffda_da_120 = 'Darmstadt: Mollerstadt',
                ffda_da_130 = 'Darmstadt: Hochschulviertel',
                ffda_da_210 = 'Darmstadt: Johannesviertel',
                ffda_da_220_230 = 'Darmstadt: Martinsviertel',
                ffda_da_270 = 'Darmstadt: Bürgerparkviertel',
                ffda_da_310 = 'Darmstadt: Am Oberfeld',
                ffda_da_320 = 'Darmstadt: Mathildenhöhe'
        },
        hide_domains = {}  -- domain_name wouldn't be part of the dropdown, but other domain names might still need hiding, idk

This is not well fleshed-out, I just needed to write something down so we don't forget this problem all multidomain communities are currently facing.

[AiyionPrime]

I've been looking for something like this in gluon, a few days ago.
For now I've averted the need by using a translation file, which resolves bat devices to domainnames, but that won't be enough in the long run, particularly with regard to the easier ex- or interchangeability between different tools like batman and babel.

I have no strong opinion on how to implement this; whatever comes out of this, I'll gladly implement its use in mesh-announce, whenever this is concluded.

[lemoer]

Currently we have implicit 1:N allocations between L2 network and domains: There are two reasons for this:

1. Allow the firmware user an easier selection in configuration mode.
2. Allow existing L2 networks to be easily subdivided by simply reassigning the 'domain ⇔ L2' assignments. Since the firmware user has already made a fine-grained selection of domains, no user interaction is required for the subdivision.

@mweinelt To reformulate your "pretty_names" proposal, you suggest that we do the following:

• a) Change the meaning of a domain to: domain = L2 network (1:1).
• b) Introduce a relation pretty_names ⇔ domains (N:1).

While this would be a good solution for 1., this is not very intuitive for 2.

---

I would rather advocate making the implicit assignments explicit and introducing another instance/object representing the L2 network.

This could be implemented by:

• a) introducing a meshzone instance, which represents the domains that are in the same L2 mesh.
• b) and introducing an explicit relation/assignment domains ⇔ meshzone (N:1).

The interpretation would therefore be: domain ≠ L2 network = meshzone.

[neocturne]

I don't think we need to make this explicit in the JSON - there is already only one primary domain name based on the name of the file, and all the others are just symlinks.

[neocturne]

Shell command to get the primary domain name:

basename $(readlink -f /lib/gluon/domains/$(uci get gluon.core.domain).json) .json

We could implement this in libgluonutil and publish it in addition to the configured domain name via respondd.