...after having determined the several levels of prototyping currently employed, an important step ahead could be achieved by analysing the intended and implied usage context of this builder scheme, while still assuming the simplifications related to prototyping. It can be assumed that * the Level-2 builder object is ''somehow provided'' * the invocation happens from within a media-handling lib-plugin * alongside with the desired `ProcAsset` spec, an `ExpectationContext` will be provided, allowing to pass-through additional semantic tags The implementation in the lib-plugin is then able to draw from specific knowledge related to the **Domain Ontology** for ''especially for this library'' and provide the necessary wrappers and parameter mapping information. ⟹ the **Level-2**-builder should thus expose an API to * set up a straight forward mapping, based on a given wrapper functor to delegate to the actual library invocation * allow optionally to override some of the input connections * alternatively allow to use a complete `InvocationAdapter`, including a `FeedManifold`, as provided directly by the library-plugin |
||
|---|---|---|
| .. | ||
| draw | ||
| DIR_INFO | ||
| dump | ||
| empty.html | ||
| InterfaceConcept_Varga.mm | ||
| renderengine.html | ||
| thinkPad.ichthyo.mm | ||
| uml | ||
| workflow.mm | ||