This document defines design and implementation constraints following as a consequence of the general system requirements defined in dmfc-systemreqs.html.
See Terminology.
AC1: Issue: what does the server-based application implicate for client/server communication? Is this merely a question of building a specific client UI, or does the framework-to-conversiontype communication also need to be based on a protocol like SOAP?
AC2, AC3: Besides the command line based UI, the framework must expose a convenience class for instantiation, handling execution and messaging.
SU1: The available Transformers are not defined at the build stage. The framework must contain some sort of refreshable "registry" or "library" of available Transformers.
SU2: The framework must have the ability to analyze a sequence defined by an end user, and determine its viability. As a consequence, each Transformer must in itself define what file type(s) it requires as input, and what file type(s) it offers as output. Issue: would it be possible for Transformers to support overloading, ie several types of input (example: XML file URI | XML stream | XML file object)? It would then be the frameworks job to mix and match to get a sequence conversion doable.
SU3: The framework and the Transformers has a common language to define input and output types. This is ideally based on MIME, where a common registry defines MIME extenstions made.
UI4: This is uni- and bidirectional messaging, meaning that the framework must be able to
UI5: All Transformers must implement a "silent mode" switch. It is expected that the default modus operandi of the system is "the black box", therefore the implicit default setting of silent mode is "true".
PS1: the term "directly deployable" limits the amount of coding language choices for the framwork to the few where zero effort is needed to maintain ports.
PS2: Each Transformer must define which platform it runs on.
CL1: The framework must support execution of foreign binaries. CL1 must be taken into account when designing to support for SU4, SU5, and UI4.
IL3: Explanation: there are locales (scripts) for which unicode support is still nonexistant. For this reason we need this caveat.
IL2, IL4: all prompts of the framework must be exposed in an open format, translatable via text editor.
LM3: Conversion types should be developed with low granularity in mind. The framework must include a utility class library that provides functionality with recurring use. Criteria for when certain functionality should be included here must be established.