The hostname becomes part of the url in certain database types, such as point cloud, images, etc..
This makes the database very inflexible when it comes to changing hostnames, using https vs http, etc...
Inlead of storing the actual url, a variable substitutable url could be stored, for example
{IMAGE_SERVER}/images/12345/image.jpg
The two functionalities can be added.
Add the ability to form the real url in the DRF side. This will become the endpoint for client side code to hit to get urls that are needed. The default value for the {IMAGE_SERVER} should be blank. This way it becomes a URI that would work regardless of hostname. {IMAGE_SERVER} would only be set in the more advanced case where the image server is actually only being served from a different location. Some form of cross authentication will have to be set up for this use case
Add a function to take this url and turn it into a file location. This will be used for the django apps.
It would be best to do this AFTER history is removed (#39), and AFTER the javascript apps are re-written to use all DRF endpoints
The hostname becomes part of the url in certain database types, such as point cloud, images, etc..
This makes the database very inflexible when it comes to changing hostnames, using https vs http, etc...
Inlead of storing the actual url, a variable substitutable url could be stored, for example
The two functionalities can be added.
{IMAGE_SERVER}should be blank. This way it becomes a URI that would work regardless of hostname.{IMAGE_SERVER}would only be set in the more advanced case where the image server is actually only being served from a different location. Some form of cross authentication will have to be set up for this use caseIt would be best to do this AFTER history is removed (#39), and AFTER the javascript apps are re-written to use all DRF endpoints