C.ORE™ Standard linked-Library and Scripts can be utilized in parts or meta-structures. Parts are released in a rolling-release model, while meta-structures can be swapped out entirely with your builds or those from the community.
All of these files-types are able to be interacted with utilizing EntityScript™ and the initial version of the program released in 2020 had very basic uses attached. Even so, the program is functional. Since, the versions have been extended and tightened even more and the version 2.0 release is consumer-grade.
Each open source file will be available here soon too. Python 3.8 was used as the implementation language for version 1 and the full package has been tested on various systems capable of running the language.
Note* - This section does not include the needed folder structure, log variables, or initializer scripts. The folder structure eventually will be available to download from CORE.HOST: Download Portal. The intializers, log variable startup scripts, and other items will be able to be downloaded from https://core.host/configurations/ by the end of the 2023. Enterprise customers will have tailored access to each of the required parts to run the system in the latest branch. Until more people are using EntityScript™ those customers will get exclusive support. The technology that's being presented is for general-purpose computing, but enterprise customers can benefit from more specific services.
The default script is named the same thing as the parent first-position meta-structure, CORE.
.CORE/CORE is the default script start position and allows you to work with core.es and CONSTRUCTED_core.es from the start. The reason these containers exist in the first place is to store on the fly information in a log specific format that's intended for archiving activity. All of the other scripts don't rely on this script but are able to work with it when storing structured-data on disk in long-term archives. These .es files can be branched into a traditional database if that's what you want/need. We don't want to write any kind of data to disk that hasn't been processed into a storage format that's defined and moved out of temporary containers. We also will want access to the underlying sub-system itself but don't want to call to it directly without some convention or reasoning in mind beforehand. The default script doesn't provide system-level functions at setup, but if you need them in various situations the best place to store their linkage would be in the default script. C.ORE™ as a grouping of scripts is a interface extension methodology that's not meant to rely on the rest of the program at all. C.ORE™ has many parts that can be setup to access system-linked resources running here - or primarily through a middlelayer. There needed to be one point in the system where links between the host and the software running in C.ORE™ could be made. The default script C.ORE™ is where that happens. It can be extedned as needed.
There are also several other areas to work with too. Here is a list:
Outside of the standard configurations, program behavior, and scripting locations, new ‘pools’ of information can be localized or extended through the use of meta-specific ‘ResourcePool’ modules. These modules can occur in any meta-structure and are used to localize general program specific information into a meta-related local context.
Additionally, if you choose to provide top-level node support you can customize the initial initializers. You're able to set or extend default variables, or install root level customizations.
These files all can all be modified, extended, or for the most part - eliminated entirely at startup if you choose to replace them with other functions. Use EntityScript™ in different ways according to your needs. To see more about the startup process and interacting with these parts click HERE