Files, files, and more files. Am I contributing to implementation chaos by creating yet another file format? Not really. BAR is one of those formats that, like XML Schema, can have a “schema for itself.” You can get the BAR format specification on my website.
You have your JAR files and your BAR files. You have your EXE files and your OUT files. Code is code, data is data, and there always seems to be yet one more mechanism for interpreting the huge numbers of bytes that fly across your computer every day.
As for BAR, it has code and data, but unlike other mechanisms for general-purpose code execution or data representation, BAR is intended to be ultra-light. This means that whatever it takes to represent the contents of a file, be it code, markup, or some combination of the two, BAR gets it done with the least amount of resources.
Specifically, a BAR implementation file contains the following:
1) Header: information about the file.
2) Value table: long integers to be looked up later (enumerated constants, tokens, and critical-step UIDS).
3) Construct definitions: the “building blocks” of a file format, for the most part data representation.
4) Variable definitions: individual named quantities used to store data in structures, local variables, global variables, and parameter variables.
5) Enumerated constant definitions: collections of enumerated constants.
6) Function definitions: support functions (critical-step methods and utility functions).
7) Compiled script byte code.
8) String look-up table.
9) (Optional) The uncompiled source code.
And the beauty of all this? It fits into only a few kilobytes. Many BAR implementation files are only around 5,000 bytes!
Platform independence is a nice thing to have. It’s also somewhat taxing to design for platform independence. Many platforms, notably the Java runtime, are HUGE. This is because the runtime needs to do many things that a program is not expected to store in its own code, like compiled low-level calculation routines, interrupt callback handling, low-level network processing, etc. The operating system might provide similar services, or it might not.
What about the BAR engine’s runtime? The Win32 static library version weighs in at only a few hundred kilobytes.
The main reason the BAR engine and associated BAR implementation files are so light is that the purpose is limited. You are NOT trying to display an impressive front-end, handle real-time input, program hardware, or handle networking directly. The sole purpose of a BAR I.F. is to represent information. You can tweak a BAR I.F. to perform conversions to “cook” the data in a file, but this is optional. Use BAR to characterize primarily, and convert secondarily.
Right now, there are about 25 small, basic implementation files on the BARfly website. Not all the file formats, but still enough to characterize much of the information floating around the web. Take the average size of a BAR I.F., which is about 10 KB, and multiply by 100, and you’ve only got 1 MB worth of schemas to characterize virtually every format in existence!
It will be a good day when BAR becomes the end-all for representing file data. Contributions from BARfly Gold users will only make the job easier.
Hello. I think the article is really interesting. I am even interested in reading more. How soon will you update your blog?