It previously has been my greatest desire to make the programming interface as transparent to the many features of ARX as possible. However, now I will refrain from designing Arxx in that way for a number of reasons:
I do not yet know the complete range of functions that ARX or Arxx has to support in the future. Making it completely transparent to future needs is almost impossible and at the least will lead to cumbersome solutions or approaches that are intuitive to the beginner as they make things transparent that the beginner will never use.
I realized that even for the expirienced programmer it is not always easy to see the needs of certain constructs even if they allow a nice feature in the library but only at a certain high level of insight and usage. Most often programmers want to have an intuitive way to handle the vast functionality of a library and prefer a medium sized set of minimalistic functions with only a small depth of hidden - transparent - extra or bonus functionality.
There is indeed a considerable amount of thinking to be done about the ARX file format.
With the target community being the game developers it is quite possible that ARX, even though used on the inside of applications, has very immediate consequences on the application's behavior towards the end-user. This user of course is a gamer, generally without much experience in what makes a computer run and always ready to throw aside the mouse or joystick if a game proves instable or irresponsive. Hence one major goal of ARX and Arxx has to be directness and of course providing all the information available to the API user, to allow a user-friendly and responsive application interface.
Special interest should be given to progress bars. Progress bars possibly are the most misused or even neglected feature a user interface can use to give the end user the best possible understanding of the time needed to perform a certain task. Neglection certainly is a failure on the designer's side. But misuse can have many origins with the most notable being the absence of information about the number of things to do or the size of things to process. With those pieces of information missing a progressbar cannot even be set up correctly.
Consequently ARX has to try and avoid shortcomings like the absence of information. Sizes and amounts should be available right from the start of some task and have to be made available via the ARX API like Arxx. For the file format this primarily has the following implication: The number of items in the archive has to be stated somewhere in the archive header.
But it surely shouldn't stop there. Imagine you have an editor for ARX archives and you load a local file of about one gigabyte size. Reading an archive of this size and setting up the user interace to present such a vast amount of information to the user will of course take some time and even if we are talking about 10 seconds only it would certainly be appropriate to give control to the end user as fast as possible. So what will the end user see if he has loaded an archive? Probably not the data of some specific item but something like a list or tree of items or nothing at all but only a prepared user interface from the application. In fact it is highly unlikely that any data will concern the end user immediately after reading the archive. So why should the data be loaded as well instead of only reading the item header information required to build a list or tree of the items in the archive. Since the data stream should not be considered seekable this means that all the header information should be placed at the beginning of the file using offsets into a part of the file that only contains the data to reference the appropriate data chunks.
I have no doubts about the fact that inheritance is possible for the Library and the Item. Therefore the main questions remaining are: Is it worthwhile? Does it provide some substantial benefit above a private and non-inheritable or at least inheritance discouraging way?