Having one monolithic flatfile for everybody isn't amenable to contributions.
Part of the reason I did it this way was because I wanted to be free to use the full keyspace for node names (for cleanly-readable data) and I didn't want to deal with file restraints (or the difficulty of creating a new file), but really, I'm going to have to do that anyway.
So, here's my plan:
Filenames follow Wikipedia rules, where underscores get translated to spaces, and percent characters get URL-decoded.
Since percent-encoding happens independently of name evaluation, you don't end up with problems like percent-encoded underscores being converted to spaces, or names not allowing
Beyond percent-encoding, though, unfriendly characters will in practice just get omitted from the filename, with names that require them being specified with a name key in the YAML (which overrides the default, filename-derived node name).
So really I should probably just ditch the percent-encoding idea here, actually, since the goal of the filenames is readability and not the ability to have ugly but perfect representational translations.
Having one monolithic flatfile for everybody isn't amenable to contributions.
Part of the reason I did it this way was because I wanted to be free to use the full keyspace for node names (for cleanly-readable data) and I didn't want to deal with file restraints (or the difficulty of creating a new file), but really, I'm going to have to do that anyway.
So, here's my plan:
namekey in the YAML (which overrides the default, filename-derived node name).So really I should probably just ditch the percent-encoding idea here, actually, since the goal of the filenames is readability and not the ability to have ugly but perfect representational translations.