Thank you for those.
I'm reshuffling them a little, but I'm addressing each.
If you think you can make it work then go for it, based on my knowledge of the module system I think you will face some challenges - especially steps 7, 8 & 9.
We'll see about 7 and 8.
As for 9, I'm removing it for now. AFAIK all strings are currently being kept in memory, so keeping just those that had been loaded wouldn't make it any worse.
I don't understand why UID's 1 - 4 are reserved for module type.
Those are being (ab)used in
menu item hiding.
Limiting the system to 64 modules MAXIMUM over the lifetime of CHDK seems likely to come back to haunt future developers. Why not 99?. Or use hex values for XX and allow 255?
Who assigns the XX value? How do you avoid clashes if people are independently creating new modules?
I am operating on the assumption that string IDs remain
uint16_t. Since language files (at least now) use decimals, starting at e.g. 5121 wouldn't be very intuitive. Using 0x, on the other hand, would complicate things on both ends.
Re assigning IDs to existing modules: I could do that.
Re future ones: how many are being developed currently?
There is no obvious mapping from the module name to the XX value, this will make life somewhat harder for people doing translations.
The longest language name is 10 characters long (indonesian) so you theoretically have 5 characters to play with for XX before hitting the 32 character path limit. Perhaps an abbreviation of the module name would work, and solve some of the above questions.
How about abbreviating the language name instead? That way, we could even welcome
en-GB to the neighbourhood
