Yes, the AMLST module shouldn’t interfere with the MediaCacheLocalContent module. The amlst: and smil: prefixes are distinct from one another.
Understood. I think I poorly described my intentions, though… Here’s the behavior I have now, which is a lightly modified version of the AMLST module:
- receive amlst: request (ex. amlst:foo)
- iterate through possible renditions (ex. foo-1, foo-2...foo-5) to see if they exist in the storage directory, and generate the manifest accordingly (only containing the renditions that exist)
- return the manifest to the client
Here’s the behavior I need:
- receive amlst: request (ex. amlst:foo)
- iterate through possible renditions (ex. foo-1, foo-2...foo-5) to see if they exist in the storage directory, and generate the manifest accordingly (only containing the renditions that exist)
[b]- if nothing exists on the local server, then iterate through the renditions again, checking if they exist in the S3 bucket, and generate the manifest accordingly (only containing the renditions that exist)[/b]
- return the manifest to the client
It seems like it should be possible without too much difficulty, by combining some of the functions from AMLST some from the MediaCacheLocalContent module. I haven’t sat down to poke at it yet, but will take any advice/pointers/better ways you have.