Open BrandonBussinger opened 10 years ago
So this workflow was put together before we where all in sync, but it's worth keeping as a nice example workflow for the framework. Just to be clear though MHL is superseded by the framework's DSL and Asset ID system, so replacing MHL with C4 through this graph and making the swift object store abstract (any storage will do) we have a good example of a C4 workflow.
MHL is a great pre-cloud / offline data integrity system, and it occurs to me that we need an example to show how C4 addresses MHL use cases in the 'C4' way.
Below is a first draft idea for how the proposed asset registry service could be implemented with other tools to provide a unified "media pool" with ingestion for multiple production applications.
Through adaptation or incorporation of code from MHL (http://mediahashlist.org/) develop an ingest process in which:
-Media files are hashed with MHL on the client -Files are uploaded to an object storage repository -Files are entered in registry with URI to storage service -Files are verified against MHL -MHL are stored by MHL service -MHL service registers asset hash to registry with URI to MHL service -Media file headers are parsed by Media info service -Parsed data is stored as extended attributes attached to the object URI in a Media info service database -Media info service registers asset hash to registry with URI to MHL service -Client APIs authenticate through federated identity system -Client queries registry by ID (returns URIs) or URI (returns IDs)
This would allow applications and users with access to query files or media specific metadata (TC match, Camera Type, etc...) to bypass the need for individual application to index large storage repositories
Below is a simple diagram. Just offering this up for discussion/consideration