DCMS: Difference between revisions
No edit summary |
|||
| Line 14: | Line 14: | ||
*DCMS runs using the distributed-process family of haskell modules on MCP nodes. | *DCMS runs using the distributed-process family of haskell modules on MCP nodes. | ||
*Apps start life in discrete subject CMSes (e.g. sameboats, the public market in drupal, the admin server in django/mezzanine), migrate into the larger context as the driving case of DCMS initial development. | *Apps start life in discrete subject CMSes (e.g. sameboats, the public market in drupal, the admin server in django/mezzanine), migrate into the larger context as the driving case of DCMS initial development. | ||
*A role in the Large Systems Revival relative to MCP analogous to DMSII. | |||
Explicit Non Goals | Explicit Non Goals | ||
Revision as of 10:43, 23 September 2017
Late 2017 Story
"D" CMS
Where D can be domain(s), distributed, dominion, just D, etc., as different aspects of the generalization are considered.
Current Design Intent
Explicit Design Goals
- Reuse of unmodified existing CMS, specifically these: Drupal, WordPress, mediawiki, ecore, and mezzanine.
- Mature apps are developed as literate artifacts in the WFL book metaphor.
- DCMS runs using the distributed-process family of haskell modules on MCP nodes.
- Apps start life in discrete subject CMSes (e.g. sameboats, the public market in drupal, the admin server in django/mezzanine), migrate into the larger context as the driving case of DCMS initial development.
- A role in the Large Systems Revival relative to MCP analogous to DMSII.
Explicit Non Goals
- Work other than access controls on these CMSes: mediawiki,ecore
- Commercialization or use by others in any proximal stage of development, although it will be available and distributed with MCP.
Early Précis
DCMS is, as indicated in the older material below, a generalization of CMS. In this I have in mind a certain aesthetic which is hard to convey but one can refer to examples in historical systems. First is the AS/400 architecture in which the entire user filespace could be accessed as a relational store. The generic quality of apps in the MCP systems is a less clear but similar example. DCMS provides the reasoning support for finer level names than the domain name and is an umbrella term for all the support I provide for that.
Is a design concept of ai-integration.biz generalizing anything that could reasonably be construed to be a CMS:
- A framework in which arbitrary NixOS packages can form an integral aii.biz domain application.
- A designation or namestyle by which the derivations used in WFL/DCP are distinguised from their original distributions. In this, the form DCMS-<contentSpecifier> is used where the convention is that <contentSpecifier> will be one or two latin characters if a generic category of actual CMSes is being modeled, or a name if a specific one is.
- Example: DCMS-W would be the category of wiki CMSes but DCMS-wiki would be the mediawiki derivation ("EG") which you are working with now.
- DCMS-X is the special abstraction of DCMS realized in WFL/DCP as a dominion level subject, a concrete implementation of the LAMP abstraction based on our NixOS packages.
Historical
DCMS was originally intended to be implemented as the set of packages integrated by DCMS-X over DMS III, but the later is more approriate to another of my projects.
