Pros for locating the reflection config/metadata with the server rather than the data:
developers can see the reflection config/metadata for all map groups in one file
Pros for locating the reflection config/metadata with the data rather than the server:
a strategy, location and API already exist to find data files outside of data/view
*regardless of the subject matter, before introducing a new strategy, location or api, there should be an overwhelming reason not to use what exists
all of the data and metadata for a map is contained under the dataRoot, making copying or removal of the map more obvious
somehow it seems better for the client to retrieve map config/metadata from the data domain rather than the data server domain
Find a good home for the reflection config/metadata.
config/metadata used by:
The client uses this information to determine if the map group has the data required for reflection.
The data server uses this information to map:
access method:
The client uses the route: /reflect/metaData/mapId/
The data server reads the reflection.json file from somewhere on the data server