solidify type system
breezykermo opened this issue · 0 comments
It's become clear that we should have some sort of slim type system for elements to enhance the mtriage runtime by giving more systematic ways to deal with elements. This is crucial as we begin to support more complex selector/analyser workflows.
The first pass at this could create casting and typechecking functions for 'etypes' (element types). An etype designates the structure of media that compose an element. For example, a Video
etype will represent an element with a single file that is one of several supported file extensions (.mp4, .mkv, etc).
Etypes are mtriage's way of translating elements from storage (on the filesystem) into runtime-ready data (via Python). Etype 'casting' is the process of inferring an element's etype by reading the filesystem and matching the file extensions with supported etypes. It is possible to implicitly cast between elements on the filesystem and etypes because an etype is a kind of higher-level, mtriage-specific file extension. There do not exist etypes that differentiate between elements with the same set of filetypes (e.g. two elements that each contain a single .mp4 file), as an etype should be nothing more than a 'naming' of a filetype or set of filetypes.
Etypes allow selectors and analysers to validate input and output data. Analysers may only support processing elements of a certain etype (e.g. Video), and produces elements with a particular etype (likely but not necessarily different from its input elements' etype). Mtriage should throw a descriptive error when a user attempts to feed an analyser input elements of an unsupported etype.