For IDA, this is when you decide that your derived manifest is good to go, and you want to tell Omeka about it. You can do this per manifest, on the completed screen, or for all the manifests at once on the completed screen.
Sorty needs to do two things:
- make an API call to Omeka S to tell it about the (Presely-hosted) manifest
- Add an extra service to the manifest to record the fact that it has been pushed, and PUT the manifest back to Presley
The "completed" screen then knows which ones have been pushed and can convey that visually.
I don't think we need to tie this too closely to Omeka (although we can to get it done as a first pass). Sorty has a pluggable strategy for notifying an external system (in this case Omeka S) that a manifest is ready, and a means of storing the fact that it has done this on the manifest.
Sorty should add to the service the response it got when it pushed the manifest to the external system (e.g., any response body, status code)
We can make this work specifically for Omeka first time round.
For IDA, this is when you decide that your derived manifest is good to go, and you want to tell Omeka about it. You can do this per manifest, on the completed screen, or for all the manifests at once on the completed screen.
Sorty needs to do two things:
The "completed" screen then knows which ones have been pushed and can convey that visually.
I don't think we need to tie this too closely to Omeka (although we can to get it done as a first pass). Sorty has a pluggable strategy for notifying an external system (in this case Omeka S) that a manifest is ready, and a means of storing the fact that it has done this on the manifest.
Sorty should add to the service the response it got when it pushed the manifest to the external system (e.g., any response body, status code)
We can make this work specifically for Omeka first time round.