Capability Letter Choices
We assigned user capability characters using only lowercase ASCII letters at first, so those are the most important within Fossil: they control the functions most core to Fossil’s operation. Once we used up most of the lowercase letters, we started using uppercase, and then during the development of the forum feature we assigned most of the decimal numerals. All of the lowercase ASCII letters are now assigned. Eventually, we might have to start using ASCII punctuation and symbols. We expect to run out of reasons to define new caps before we’re forced to switch to Unicode, though the possibilities for mnemonic assignments with emoji are intriguing. 😉
The existing caps are usually mnemonic, especially among the earliest and therefore most central assignments, made when we still had lots of letters to choose from. There is still hope for good future mnemonic assignments among the uppercase letters, which are mostly still unused.
Why Not Bitfields?
Some may question the use of ASCII character strings for capability sets instead of bitfields, which are more efficient, both in terms of storage and processing time.
Fossil handles these character strings in one of two ways. For most HTTP
hits, Fossil expands the string into a struct full of
flags so that later code can just do simple Boolean tests. In a
minority of cases, where Fossil only needs to check for the presence of
a single flag, it just does a strchr() call on the string
instead.
Both methods are slower than bit testing in a bitfield, but keep the execution context in mind: at the front end of an HTTP request handler, where the nanosecond differences in such implementation details are completely swamped by the millisecond scale ping time of that repo’s network connection, followed by the required I/O to satisfy the request. Either method is plenty fast in that context.
In exchange for this immeasurable cost per hit, we get human-readable capability sets.