What we do is called informatics, we are supposed to build information systems. The tools we use for that are the computers, which can process and transform the data, and the way we instruct the computers to process some data is programming. So we are programmers. And all that we have to do our task are tools for programming: different (and numerous) programming languages, different (and devastating amount of) tools to process a certain type of data in a certain way. Finally, we implement software: a collection of algorithms that can be executed in a specific environment: hardware, a certain set of operating system version, or higher level runtime, using a specific set of tools of a specific set of versions. All that we have investigated and found out of data is burnt and hidden into this implementation and execution environment. When it changes, and for all the other, simultaneously existing environments, we have to do the same thing again and again.
If we look at it from the business viewpoint ("work to get money"), this is good. But from any other aspect, ("work to solve a problem in a way that it also remains solved for a considerable amount of time"), this is totally, fundamentally wrong! To correct it, we should return to the basics.
We are supposed to build information systems. The key is the piece of information itself, not how, where, when we process it. The information system is a parallel universe that lives synchronously to the material world; the information system should hold a "shadow" of existing things - exactly one, unique instance that can follow that material (like a person or a car), or conceptual (like a calendar) entity. Dust Framework aims to support building this information system by extracting the concepts, types, pieces of information from the actual implementation environment to a declaration level. It is not dependent on any external framework, only upon itself: the meta-language of declaration (basic terms and their relations) itself is just a declaration, can be corrected or upgraded on need. The actual runtime services are atomized and therefore are wrapped into several black boxes. The representation of this content is also irrelevant: the same entity hierarchy can be stored in a database, LDAP server, in the structure of a file system, or in files of XML, JSON or whatever format.
Data access
The concept is nice, but has very complex consequences. For all execution environments, "data" is a tagged location in the system memory (temporal data storage area), and all we actually do is instructing a piece of hardware, the processor, to do something with the information at that location (read, test, change).
However (except for local, temporal working variables), "data" is not just a location in the system memory: it represent a state of an object in the external world. That object might be visible in other execution environments in this very moment, it might change as I watch it, and it may live longer than my environment (may have existed before I switched my machine on, and will exist when I switch it off). Accessing this piece of information is definitely not that easy as a processor instruction. It is essential how I get, lock and commit (or rollback) this data.
Get data
Lock
Commit / Rollback
