## How to manage the loading process

### Ideal

#### Use cases

1. Filename is in the filesystem namespace. Fileformat identified by file contents.
2. Filename implies a set of files. Files are in the filesystem. The existence of the files triggers full attempt to load files. The file contents confirm the filetype.
3. Filename is URL. The file contents identify format.
4. URL implies a set of files. The existence of the resources triggers full attempt to load files. The file contents confirm the filetype.
5. Filename describes image in entirety
6. A loader plugin can take a filestream.
7. A loader plugin can take a filename, and recursively issue another load command
8. A loader plugin may need to know the filename while taking a filestream?

#### Design

Several lists of loaders.

1. First list decides what to do purely on basis of filename, and includes.
   1. filename encoded image loader
   2. Image cache plugins
   3. URL Loader loads into memory, and passes stream to level 2
   4. File loader creates file stream, and passes to level 2
2. Second List takes stream and filename.
   1. Simple file format loaders.
   2. File format loader that then needs to load subsequent files

### Practical

This is getting too messy. Instead we will start with a single list of loaders, that will each get a chance to load an image based on a filepath. In all other respects the loader should be like the vil loader. It should load an image view by

1. Passing the filename (not open stream as in vil) to a sequence of loaders
2. Each loader should attempt to determine relatively quickly if it can load the filename
3. The actual filename(s) to be loaded can be inferred from the filename - they need not match precisely.
4. As a loader attempts to read the file, it can abort at any time, by returning a null image_resource_sptr
5. When all the image header details, etc have been read, the image loader will return a formed image_resource
6. The vil3d_load function (or client) can then call the resource's get_view() to read the image.

#### Use cases

That should allow the following use cases.

1. Filename is in the filesystem namespace. Fileformat identified by file contents.
2. Filename implies a set of files. Files are in the filesystem. The existence of the files triggers full attempt to load files. The file contents confirm the filetype.
3. Filename describes image in entirety

## How to save files in vil3d

No file saving routines have been written, but place holders for various parts of the saving system are in place.
I recommend that you follow the pattern used by vil. It may be complicated, but it had many advantages in dealing with large files, and header information. As with the loader, vil3d saver should pass around filenames to image_format::make_output_image(), so that multiple slice filenames, etc. can be inferred.

Ian Scott.