Hosting a Server
The StuphOS application library is connected to its embedding context at a low-level, meaning that you can provide fast logical implementations compatible with its governing of universal data and process integrity.
One can assume that the embedding context is inherently and relatively faster, because overhead is not associated with plain computation as much as the rest of the library's feature value: the Very High Level Layer (VHLL).
The platform ultimately gets its basic operational code (compute) from an online code editor and deployment interface. Permission-based trust and authentication secures the read, write and execution activities of its database.
You participate in building the site which controls the appearance of OS-level functions, like a REST API or XMLRPC session. Using components such as these, you might connect them to a database, or the current system messaging and peer to peer configuration.
Virtual Compute Architecture
The Elemental VM and StuphOS runtime architecture allows passing of executive control to native Python functions and callables whose return value is expected to be an object that conforms with security and containerization in mind, since it is pushed onto the task stack and is accessible to virtual programs. When combined with a bound initiating context or scope variables, we control universal object access and use Python to implement memory allocation by quota and generalized executive access control.
- First, we extend and alter the Python object model:
- With getattr functionality, but the language restricts access to “private” attributes starting with an underscore.
- Then, we implement a virtual machine to define and provide operations for accessing/manipulating objects. This VM is restricted like a (Lambda) MOO.
- We provide a modularly-defined database object model for data and code representation.
- Networking & Multi-user management is introduced.
- Memory usage is restricted to a user’s quota-based allocation. CPU usage is tracked.
- Each layer is connected via a stabilized API.
The objects and relational data contained in-memory depend on the embedding context. In multiplayer games, objects are connected in a way that describes the world. Usually the graph is entered at the user authenticated event point and can thus access the associated character, location, inventory and peer references; the underlying game objects (entities) are accessed with a security context. In the case of the stuphmud.adapters module, when a link is requested between entities, the context is an accompanying 'perspective' pointing back to the adapter encapsulating the link and is used to differentiate access to properties or verbs.
In-memory objects controlled by the language are essentially Python objects, so they can be used in mathematical and instructional operations like add or subtract. Also, as defined by Elemental, they may have methods that are either implemented as native Python functions or Procedures that are executed by the Elemental VM scheduler. And, attributes are exposed, however, attributes whose names start with an underscore (_) are considered private and are generally inaccessible to the Elemental VM.
Edit and load code modules over the web with an online IDE. Anything you can enter into the console can be automated with a script.
The requirement of a programming language originates from the interactive command-line experience of the MOO. Multiple commands batched together and structured programming syntax implements microservices in terms of individual instructions run within the server vm.
The motivation behind new code and not say, hacking PyPy, is in not trying to emulate a precise version of Python. Moreover, the language design is guided by emulation of the MOO VM.
Agent System Library
The two primary types of resource in the library are activity modules and interfaces. Both are represented by text documents, but are used in different ways. Interfaces are commonly used for the purpose of addressing and serving web views. The url path is used to step into the library tree, and then into the YAML structure of the interface document to find a named view that can be processed for each web request. Interfaces can also be loaded from running programs using the 'structure' native, and are loaded such that uncontrolled access to the memory is protected meaning allocations are limited by user quota.
Writing a Service Facility
A service is an object that is loaded from the python import system, initialized in python and then set in the registry with a pre-specified name. Services are set in the configuration under the Services section.
Each option's key name must begin with the identifier 'facility.' and can follow with anything. These keys are first sorted in alphabetical order and then loaded that way, so you can specify that a service load before or after any others by sequencing this key name.
The option's value is a fully qualified python package/module import name that specifies a module on the python path as well as the last attribute dereferencing an object class within that module. That class is then instantiated during registry configuration and the service is started and stored.
Writing a Native Tool
A native tool is set in the configuration under the AgentSystem section. The tool's scope contains members and functions available to the executing agent.
path: the path in the agent system where the scope of the tool is hosted. package: a fully qualified package/module import name that must be on the python path. Cannot be combined with filename. filename: a local filesystem path specifying a script to load the tool from: .py: load a new dynamic python module initialized with the code in the script file and set that module as the native tool scope .wmc: requires WRLC. Load a YAML structure from file as tool scope. Cannot be combined with package. access: optionally, when filename is .wmc. A dot-separated list of attribute strings that are sequentially accessed from the top of the structure. The last attribute is stored as the tool scope.
Agents are Asynchronous
Programs in the agent system are effectively interrupted, periodically, allowing multiple user tasks to execute concurrently. In contrast, Python is a synchronous language because even with async def/await it still relies on explicit program- pausing statements in the code in order to yield. Similarly, greenlets allow task switching but only with explicit calls in the python code.
One way to think of the platform is that it exposes computational capabilities and the python runtime by embedding it in any variety of program, while limiting storage and executionary resources. When enabling an object model as a network service, use the StuphOS library as a layer in between your program and your users to organize access.
Users should be concerned by the platform only to use it to generate (or view) content, and be aware of permission requirements when doing kernel-specific actions, or, when programming access by granting these permissions for agent system access by user identities.
Termination & Stepping Control
The phaseware kernel avoids relying on pthreads or native threads so that it can decide when to suspend or terminate a task, and instead relies on a hypervisored virtual machine to sequence multi-tasking instructional contexts. This separates individual thread-like execution continuations into systematically controlled units while providing seamless interoperation of all commands, triggers and library program code. In this system, memory and database resource usage is tracked and constrained by user allocation limits.