Hi list, I'd like to get some feedback about a possible small addition to the sample converter set.
The idea would be a string converter tentatively called "reverse_fqdn". Its purpose would be to transform an FQDN-like string into a reversed dotted form so that domain-suffix matching can be expressed as a prefix lookup. Examples: "google.com" -> "com.google." "mail.google.com" -> "com.google.mail." "google.com." -> "com.google." The use case behind this is to express a rule as a domain name and have it cover both the exact hostname and its subdomains, while still remaining strict on label boundaries. In other words, one generally wants: - "google.com" to match "google.com" - "google.com" to match "mail.google.com" - "google.com" not to match "evilgoogle.com" - "google.com" not to match "google.com.evil" The reason I find this interesting is that today this naturally looks like a suffix-matching problem, thus something to solve with "end". But "end" is list-based, so larger rule sets remain linear scans even if the cache helps in practice for hot lookups. It also looks less attractive when the destination set has a high cardinality or when the rules are updated often enough for the cache to be of limited help. On the opposite, "beg" benefits from the tree-based lookup path. Reversing the labels turns the suffix problem into a prefix problem: - "google.com" becomes "com.google." - "mail.google.com" becomes "com.google.mail." With the trailing dot, the label boundary remains explicit, so a prefix lookup can naturally distinguish "com.google." from "com.evilgoogle.". At a high level, the expected semantics would likely be: - input type: string - output type: string - no arguments - one optional trailing dot on input ignored - trailing dot always present on output - failure on malformed dot structure / empty labels What I'm mostly trying to assess is whether such a primitive makes sense in the converter set at all. On one hand it looks small and composable with existing mechanisms (host_only for example). On the other hand it may be considered too specific, or it may be preferred to solve this class of problem differently, for example via a dedicated matching method instead of exposing the transformation itself. Would such a converter look acceptable in principle ? If yes, I can work on a concrete patch. Thanks, Manu Nicolas
