Editing Programming Language (section)

=Binary File Design - Ideas for good Practices=
* Magic Number - Make it easy to identify files. Might as well use human readable ASCII...
* Versioning - Make it future proof.
* Backwards compatibility when possible
** Might be kind of hard.
** With a fixes structure, adding an new element would break things.
** Would need to specify each element and give them a ID.
** Could encode size of the 'block' and make sure new elements are added in order. Older consumers can skip the extra bits.
** Older consumers can leave the extra bits in place when saving to prevent loss of information.
*** Blocks left in place without understanding could break things (ie I rename something in an old version that is mentioned in a new section but don't update it's entry).
*** Could maybe be avoided by making sure the first version, ie the 'core' is ready for new things. For example if rename is a possible issue make sure there is a structure in the first version that the new block uses rather than the new block having to be updated.
** Maybe embed a 'minimum' version number as well. Ie this new feature breaks compatibility. Maybe a read only minimum version too.
** Worse case scenario, could put scripts into the files themselves and specify that they are run at appropriate times (ie on open, on save). That could massively increase binary size since you might need to implement the entire parser in the script (although this is only on a breaking change). Alternatively allow the old parser to be used by the script. Also possible security/abuse/prank issues. Probably better to just break compatibility.
** Maybe the parser could have a update able plugin system. If you have a new incompatible file, it could tell you to download the new version which is a dynamic library/script put in the correct place but external to the file. Still seems a lot of work.
* Try and use a flat structure.
* 'pointers' are a pain. Only an issue for serialisation of stuff that uses pointers. Just don't use pointers, instead have some index. Having said that pointers would be somewhat faster at runtime. Of course they would need to be serialised to an index anyway, so that's really an implementation optimisation).
* Specify a fixed [https://en.wikipedia.org/wiki/Endianness endianness]. Both RISC-V and x86 use little. That's what I like anyway.
* Have a nice specification.
* For an added bonus make it parsable (not sure of many decent binary file schemes, maybe capnproto?).
* UTF8 for strings.
* Would a 'capabilities' block be of any use (Wouldn't this be stored in the parser based on the version number)?
* Don't store date/time. Breaks hashing.
* Hash/checksum. (At the end?). Obliviously the hash/checksum shouldn't itself be hash/checksummed. Otherwise it could be stored as part of the normal fileformat but zeroed during the hashing process.
* Store expected file size? Is there any point? Might provide a quick way to find if the file is half missing. If the 2nd half is missing the checksum would be too...
* Have a look at NBT.txt (Minecraft)