Hi List, I'd like to discuss something that's bothering me for quite some time now: The naming, namespacing and discoverability of fetches and converters.
Frankly, it's a small mess right now. I assume this is due to historic growth an features being added over time. Let me give a few examples: I want to encoded something using base64? I use the `base64` converter. Decoding? **Obviously** that's `b64dec` ;) Hex encoding? Easily done with `hex`. Decoding back to a string? Not possible. But you can to `hex2i` to turn a hexadecimal string into an integer. We have `url_dec`. But there isn't an `url_enc` or maybe I am just not able to find it. Then there's quite a few redundant converters. We have `sha1`, then `sha2` and most recently we have `digest`. Then within the description of the converters the variable naming and scoping is explained over and over again for each converter that takes variable names. For fetches it's not as bad, many have proper prefixes. But there's also a difference in naming. Sometimes the namespace is separated by a dot (`req.hdr`). Sometime it's an underscore (`ssl_fc`). Long story short: Is it feasible to update the canonical names of fetches and converters, preserving backwards compatibility with old versions and adding the missing "duals" for encoders / decoders or do we have to live with the current situation. ------- Let me give a proposal of what makes sense to me: Make 's.' contain string related converters. s.field() instead of field() s.word() instead of word() s.json() instead of json() Make 'http.' contain HTTP related converters. http.language() instead of language() Make 'math.' contain mathematics related converters. math.add() instead of add() math.sub() instead of sub() Make 'enc.' contain encoding related converters. enc.base64() instead of base64() enc.unbase64() instead of b64dec() enc.hex() instead of hex() enc.unhex() being the new reverse of hex() Make 'sec.' contain security related converters. sec.digest() instead of digest() deprecate sha1, sha2 in favor of digest() sec.secure_memcmp() instead of secure_memcmp() You get the concept. The biggest benefit to namespacing for me is that related converters appear below each other within configuration.txt. The most commonly required converters could still remain in the default namespace (or perhaps rather aliased into the default namespace). I don't believe that 's.' for the string stuff is too bad, though. Opinions? Best regards Tim Düsterhus
