Re: [AD] Adding save/load font functions

[Michael Bukin <M.A.Bukin@xxxxxxxxxx>]

Here are my messy opinions on the subject.

There were some talks about new datafile system, something like "open
file, pass file handle to decoded, pass decoded file handle to
decompressor, use provided functions to read from decompressed decoded
file handle (all file handles on this chain are the same,
e.g. AL_FILE*)".  Data source for such file may be memory, file on
disk, file from network, compressed, encoded etc.

If this system will be used in Allegro, there will be functions for
saving/loading Allegro objects to/from AL_FILE (or any other name you
like).  There are two reasons for making them static: reducing name
space pollution and reducing linking time.  Name space pollution is
not an issue in prefixed Allegro, linking time will not be affected
very noticably, IMHO.  So, I don't see any good reason to make them
static.

For datafiles (collection of Allegro objects in memory) there are two
low-level functions that do most of the hard work:

AL_DATAFILE *al_load_datafile (AL_FILE *file);
int al_save_datafile (AL_FILE *file, AL_DATAFILE *data);

Each object has type, data and properties.  Loading function reads
object type and calls function, which is determined through the table
of registered object types.  There might be another table with object
type -- file extension associations, to keep Allegro objects in
regular files (not necessary if all objects in files have IDs attached
to them).

In short :-)  IMHO, it is necessary to define datafile API first, and
then decide if there are any reasons to have no defined representation
for Allegro objects in a file and if it is necessary to hide functions
for loading/saving these objects.

-- 
Michael Bukin