A containerist hub is a server which displays and serves containers and stacks. Hubs can serve as nodes of a containerist mesh network on the open internet, serving containers to their own and foreign stacks.
Hubs can be very specialised, like only storing/retrieving static containers, only dealing with images or only serving a blog. Or they can be as general as delivering all functionality which a standalone website needs.
In here, I outline the building units of which a hub consists, starting with smallest units.
A container is a self-sustained, stackable unit for transporting data.
A container consists of one or more sections. A section is a piece of standardised data. It may contain structured data (formatted e.g. in yaml) or unstructured data (formatted e.g. in markdown) – its source.
Sections are of different section types. Each type is usually of a specific structure. In order to be displayed on the web, a section type has a skin. Examples of types: article, teaser tiles, navigation, announcement. When skinned, a section is self-sufficient and does not interfere with other sections in its display and user interactions.
A container origin is the URL of the container. It usually has the ending ‘.ctn’. Through that url, the container’s source can be accessed. The origin is obligatory.
A skin is a template consisting of HTML, CSS and JS, into which the source of a container’s section is rendered, so that the container’s content can be shown and interacted with on the web. Usually ‘skin’ refers to a set of templates for different section types, with a common design. The transformation from source to rendered HTML is called skinning.
A stack is a ordered list of container origins. The stack can be displayed as a web page. The list is called the payload. Apart from the payload, the stack usually tells its skinner and its base.
The payload is the ordered list of container origins of a stack.
The stack’s base is part of any origin of the stack’s containers. Usually it is it’s own URL. Example: if the base is ’http://my-domain.com/some/path/’, and one container’s name is ’about.ctn’, then the container’s full origin is ’http://my-domain.com/some/path/about.ctn'.
A container hub is a system for delivering, displaying and managing containers and stacks. It is usually located on a web domain and often appears as a web site. In the case of being a web site, apart from delivering ‘web pages’, a hub maintains basic containerist functionality like serving container sources and stack sources, so that other hubs can get these in a structured, machine readable way. Often, a hub also informs reveals available containers.
A mod is the core unit of the containerist hub. An abbreviation of ‘modifier’, it is a function which can be called from within code or through a http request. It accepts standardised input (e.g. GET parameters), and standardised output (a container source in yaml, markdown). Mods read data, modify data, calculate or do any other kind of operations. One mod usually does one specific task. Mods are used within other mods.
A module is a set of mods, functions and data which make up a feature or functionality. A module usually provides mod containers which can be used within stacks. A module usually consists of functional mods, mod containers, content storage, content prefills, settings and admin interfaces.
A repo is a data storage of containers and stacks. The stacker uses it in order to provide lists of available containers for stacking. hub can have one or many repos. A repo can hold a project or a user’s website.
A static container is a container which does not need any transformation before its skinning. Its source may be stored as a text file.
A mod container is a container generated by a mod. Looking at an origin, there is no difference between a mod container and a static container. If a stacker is used, a mod container appears in the list of available containers.
A container id e.g. ’intro.ctn’ is the pointer to a container within a repo, where is unique. It ends with the suffix ’.ctn’.
Each stack has a stack id e.g. ’about--jobs’ or ‘articles--var’. The stack id is used only internally within the stacker and the data storage. The stack id never has a suffix or slashes.
The stack path e.g. ’about/jobs’ is used in order to render a stack. Each path leads to a stack with a stack id, which is then rendered and displayed. The path may differ from the id in that ‘about/jobs’ may refer to the id ‘about--jobs’ or ‘about--var’ or ‘index--var--var’.
The repo id is the name of a repo. It is unique within a hub. Usually it is the first part of a url path, e.g. ‘/john_d’.
The domain is the web domain of a hub.
The stacker is a module. , an editor for stacks. In there, new stacks can be created, stacks can be edited and deleted. This manipulation of stacks is called stacking. The stacker cannot edit any container’s content; this is done by the storer.
The storer is a module. It’s an editor for the content of a container.
The skinner is a module, which renders the node's source into html. It applies the skin to the container sources.
(cc-by-sa) since 2005 by Konstantin Weiss.