Currently there's no specific spot to place storage definitions. Spitfire has a functions file, buried deep within the framework itself and not really intended as a user modifiable space. On the other hand, the environments file provides a user configurable location for settings, but a bad one for storage definitions, which are a bit more technical - and would be more fit to developers or system operators rather than users deploying an application.
Usually an application has the following predefined definitions inside of Spitfire:
$dispatcher = new \spitfire\storage\objectStorage\DriveDispatcher(); $dispatcher->register(new \spitfire\storage\drive\MountPoint('file://', '/')); $dispatcher->register(new \spitfire\storage\drive\MountPoint('app://', basedir())); $dispatcher->register(new \spitfire\storage\drive\MountPoint('temp://', sys_get_temp_dir()));
These allow an application to access a file like this:
And in combination with the Environment class something like:
This is fine, but the way these are registered leaves a bit to be desired.
The current implementation distributes the file system definitions across two locations. On one hand, the spitfire\core\functions.php file. On the other, the bin/settings/environments.php file for user defined storage definitions. It would be much easier to manage the entire system if there was a single bin/settings/storage.php file that contains all the definitions.
Placing all storage definitions in the environments.php file would be possible, and would result in less clutter on the file system. A single file that contains all the system's configuration sounds promising, but could also lead to users being confused about the options. A storage.php file could also almost create a dialogue between the system operator and the developer. The developer can define an unlimited number of storage endpoints in their application code that would then be assigned to physical locations by the system administrator when deploying the application.
Option A: An additional storage definition file
A storage.php would have the following pros:
- Setting segmentation. The user would immediately know that storage definitions are supposed to be found in this file.
- Noob deterrent: If a user feels like changing application settings, they head to environments.php. They would not immediately venture into storage.php
But it also has a series of cons:
- File system clutter. This file needs to be managed separately by CVS, Configuration deployment scripts, etc. Which adds additional workload
- Potential confusion. While it should be mandatory to write config into this directory, PHP won't enforce it. Making it hard to actually ensure the code is where it's supposed to be.
Option B: Moving all the settings to environments
This is another very promising option, which assumes that the environments file is only ever managed by system operators anyway. It assumes that only settings required to make the application boot are supposed to be included in these files (storage, database, network, authentication, etc). It has the following pros:
- With a single environments file, you only have one file to be excluded from git, only one file to push via configuration management, and the option to remove the file entirely and push the configuration to the system's environment.
- A single location to put user config into.
- Environments are built so they can deploy across several servers and load conditional configuration. The config on the live server could be different from the one on the stage server and that could be reflected. But this is rather minor pro, since I think that multiple environments on a single system are starting to get deprecated.
But it also has a series of cons:
- Users may consider static application settings to be user editable. The application may require the temp directory to be somewhere specific, and would have a hard time dealing with the fact that a user changed it. Although this is bad application design, it's sufficiently common.
- The environments.php file may get cluttered.
I think I need your input @sebastian , thoughts?