Question for Riddhi Jagdish Patil:
Regarding option 1:
To install an App, IGB sends a request to App Store.
Currently, all the requests look like:
- https://[App Store domain]/media/org.lorainelab.igb.protannot/releases/9.5.0/protannot-9.5.0.jar
When App Store receives such requests, it actually ends up sending the resource at:
- https://[s3 bucket domain]/media/org.lorainelab.igb.protannot/releases/9.5.0/protannot-9.5.0.jar
This occurs because we configured App Store's Apache server to redirect clients over to the S3 bucket domain whenever such requests contain the string "/media". All of that is happening in the Apache layer, not Django.
That said, we could implement a new endpoint that is entirely computational.
Our new endpoint could look like this:
- /bundles/org.lorainelab.igb.protannot/releases/9.5.0/protannot-9.5.0.jar
Notice "media" is gone.
This endpoint then responds to the above request with its own re-direct to:
- https://[s3 bucket domain]/media/org.lorainelab.igb.protannot/releases/9.5.0/protannot-9.5.0.jar (if S3 bucket is being used)
or to:
- https://[App Store domain]/media/org.lorainelab.igb.protannot/releases/9.5.0/protannot-9.5.0.jar (if S3 bucket is NOT being used)
We can implement this using Django paths and redirect command - see https://www.tutorialspoint.com/django/django_page_redirection.htm.
To implement, we modify "obr" in our project to ensure that if anyone ever needs to modify this business logic, they will know where to look.
It's only purpose would be two-fold: to record such requests in the database and redirect client requests to the location of the jar file. The only tricky part is making sure it's smart enough and flexible enough to handle our dual case of local storage (/media) or cloud storage (S3). For that, we look at how jar files are getting saved and use a consistent approach.
At the same time, we modify the repository.xml endpoint to use the new path to ensure IGB hits the new endpoint.
In this solution, we use Django to execute the re-direction whereas now we are using Apache to do it.
We can handle the other digital assets in exactly the same way as now. No changes are needed.
cc: Riddhi Jagdish Patil
cc: Sameer Shanbhag
Professor,
There is one more case in downloads functionality which is not handled:
Do we need to handle this case?
Probable solutions-
1) When an app is downloaded from IGB, create a REST endpoint in Django which will be hit by IGB with Bundle_SymbolicName and Bundle_Version of downloaded app which can be stored in database.
2) Remove Install app button from IGB App Manager
cc. [~aloraine]