Input Processing Output
In this paradigm, where the system operates in the environment Internet, Boxary clearly takes the process box. And, as opposed to application modules, the input is NOT a database model with user data, nor a stream with application data. It constitutes a query, command, request and such. Also, the output is NOT a signal that can trigger feedback. It will be an extract of the user data resting within the storage layer.
All input is coming in thru internet protocols; that is, the underlying protocol (i.e. its syntax) is of interest. Variations are HTTP(s), REST, SOAP, WSXL In Boxary, this input data is merely interpreted as configuration parameters, commands, and identifiers.
All output is generated and/or assembled thru Templates. Boxary takes variations called snippet, templet, and template.
HTML pages are rendered using a sophisticated layout concept. Web services deliver clean XML or JSON.
Processing is parameterized by a mode parameter: list, view, edit, count.
Modules prepare for a specific App, than invoke that App's control. This will load input data, load the Graph, walk the Graph to collect (harvest) the needed data, run the transaction if any, persist the result, produce the result output.
Input Processing Output with Storage
Now, let's pretend the storage is an archive, or, at least, it can be handled as such. Inspired by the Open Archive Initiative, all input obey the rules set for harvesting metadata. With this in mind, the input can be seen as metadata that may trigger configuration(s) and contains identifiers (search criteria). The output is a response in a specific format.
Implemented in OAI are the concepts for repository, dataprovider, serviceprovider, dataharvester, dataaggregator, using terminology like identifier, item, record, set.
These OAI concepts are very useful in Boxary. Practically spoken, the serviceprovider concept is ambiguous because Boxary utilizes its own, and closed environment. But it could be attached to Boxary's main class as a container that injects the described providers above. Such a container could provide a service like a phone book.
Furthermore, the dataprovider concept can be applied to some input protocols.
All user data is stored within a relational database; ex: mySql, Maria, Postgres.
Application configuration, model parameters, templates are stored as flat files in the filesystem.
Having said this, a slight optimization can be added to the input layer: because the input in Boxary's case is NOT metadata and the distinguished OAI entities are NOT organizations in Boxary.