Scripting
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.
Property Table
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:
ID | name of part | type of part | description of part |
---|---|---|---|
1 | all_packages | part | The exact packages running within the virtual environment at this time |
2 | build_list | part | The general packages running within the virtual environment at this time |
3 | core_add | part | core_add is a module to make, create, alter, and reseed both 'LOCAL', 'SYSTEM', and 'GLOBAL' communication attributes, including 'logs of last resort'. |
4 | core_alerts | part | core_alerts is a module to establish alert markers and related behavior |
5 | core_architect | part | core_architect is a module to establish a handlers for various digital groupings. You can either account for those groupings or use them to make quantified/qualifying output according to base example methods. |
6 | core_build | part | core_build reads system resources and makes determinations about build or system choice made by the operator. |
7 | core_config | part | core_config allows you to turn certain system modules on or off at setup |
8 | core_count | part | core_count counts entries in your core.es quick context-file and checks to see if the system is currently counting time |
9 | core_creator | part | core_creator allows you to create a .entity/.ds relationship in text-mode and system routines for modules running within C.ORE that rely on add/edit/delete methodology |
10 | core_FRONTEND | part | core_FRONTEND holds human-to-machine interaction code in a user-defined interface |
11 | core_gatekeeper | part | core_gatekeeper handles default authentication tasks and will permit or kick members according to set definitions |
12 | core_gather | part | core_gather gives the operator methods for locating .entity/.ds relationships with dlist_drill() |
13 | core_graphics | part | core_graphics gives basic X, Y, Z coordinate systems for use within C.ORE |
14 | core_hash | part | core_hash provides setup routines that can be extended into useful communication methods in C.ORE |
15 | core_interface | part | core_interface is the call logic to system interaction scripts and other 'system resources' such as audio, visual, or bus programs |
16 | core_language | part | core_language can serve as a language check script and enforcement mechanism. |
17 | core_middlelayer | part | core_middlelayer lets you extend your core_settings file into manageable write protected sections |
18 | core_modify | part | core_modify allows you to perform basic read/write operations in C.ORE |
19 | core_navigator | part | core_navigator lets you connect your interface into various parts of the underlying machine |
20 | core_openpackager | part | core_openpackager manages package meta-data and system package inspections |
21 | core_operations | part | core_operations is the default helper stack for C.ORE containing useful classes and methods |
22 | core_RUN | part | Tie a system routine to the C.ORE activation method |
23 | core_seeker | part | core_seeker gives a basic seek system for text-mode |
24 | core_server | part | core_server manages your personal server instance |
25 | core_settings | part | core_settings is the default configurations reader and read/write configurations slug_maker |
26 | core_START_SERVER | part | Tie startup routines to the server startup instance method |
27 | core_transmitter | part | core_transmitter takes I/O tasks and turns them into phase based threads |
28 | core_url | part | core_url holds retrieval methods for URL and other network based operations |
29 | core_view | part | core_view allows you to view various objects in C.ORE |
30 | MANIFEST | part | File add manifest |
31 | setup | part | Setup the program and view base package meta-data |
32 | .CORE/ | meta-structure | Origin directory structure |
33 | ACCESS/ | meta-structure | Holds security slugs generated on startup and your default key files |
34 | CONFIG/ | meta-structure | Holds configuration files needed to operate various parts of the system |
35 | DATA/ | meta-structure | Holds event-data of various types |
36 | DOCUMENTATION/ | meta-structure | Holds basic documentation for the system and various interfacing languages |
37 | FILTER/ | meta-structure | Holds single use explorer entities and filter code for various public processes such as web browsing |
38 | HARDWARE/ | meta-structure | Holds the basic system hardware specs needed by C.ORE |
39 | IDENTITY/ | meta-structure | Holds operator specific system data |
40 | LICENSE/ | meta-structure | Holds licenses in use on the System |
41 | OPENPACKAGER/ | meta-structure | Holds OpenPackager related data, including both internal, external, and corehost program types |
42 | RING/ | meta-structure | Holds formatted personal data |
43 | core-env/ | meta-structure | Virtual-environment Holds the virtual environment setup code |
44 | corehost/ | meta-structure | Holds programs and scripts derived from CORE.HOST |
45 | external/ | meta-structure | Holds programs and scripts derived externally through other code repository sites |
46 | internal/ | meta-structure | Holds programs derived as standards within the system |
47 | ResourcePool | part | Create local resource pools |
48 | StandardOutput01 | part | Create a input processor fork |
49 | StandardVisualBuild02 | part | Create interface components as fork-able objects |
50 | StandardExtension03 | part | Create package meta-structures as fork-able objects |
51 | StandardDocumentViewer04 | part | Create a document-viewing standard that can be added on to allow for various desired formats |
52 | op_BROWSEMEH | part | View system visual resources |
53 | op_EVENTLOLLI | part | Ad serving and interactive display writer |
54 | op_REMINDME | part | Time-keeping mechanism for C.ORE |
55 | COGNITIVEORE | meta-structure | Personal Record of Last Resort Ledger |
56 | constructed_class | part | To build compliant meta-structures |
57 | fetch_ORE | part | To retrieve Operations Resource Enclaves existing within the system |
58 | ingest_commands | part | To retrieve Operations Resource Enclaves existing within the system |
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