Introduction
Welcome to the milestone documentation of VMContext, the bridge that binds the immense power of GRIDNET OS’s underlying decentralized state machine to the interactive realm of the web browser. VMContext, the beating heart of the system, stands as a beacon of seamless integration and accessibility, redefining the developer experience and facilitating the creation of user-interface-equipped decentralized applications. VMContext is not merely an interface, but a groundbreaking gateway that revolutionizes the way developers interact with the complex layers of decentralized systems. It breathes life into the decentralized applications, providing a comprehensive and cohesive toolkit to harness the immense potential of the GRIDNET OS. This intricate piece of design allows developers to tap into this extensive, decentralized powerhouse right from the convenience of their JavaScript environment.
It is importance to notice that this document outlines and documents CProcess and CThread objects as well, which are used as an abstraction of Processes and Decentralized Processing Threads on GRIDNET OS platform respectively. Moreover, this document it includes documentation of the CJThread class which is an abstraction of client-side threads running straight within of a web-browser (these are JavaScript based threads with mechanics attempting to ensure that they keep executing even if a web-browser is in the background etc.)
With VMContext, you gain access to a multitude of system features, significantly reducing the steep learning curve often associated with leveraging such sophisticated platforms. It elegantly abstracts away the underlying complexity, encapsulating system-level functionality within easily accessible methods and accessors. This approach empowers developers to craft, fine-tune, and deploy their decentralized applications with an unprecedented level of ease and efficiency.
As you explore the VMContext documentation, you will uncover the remarkable array of features that make it a cornerstone of the GRIDNET OS. You will discover how to command the power of the system, enabling you to shape the next generation of decentralized applications that deliver user experiences beyond imagination. We invite you to embark on this transformative journey and redefine the boundaries of what’s possible with GRIDNET OS and the VMContext at your fingertips. Welcome to the future of decentralized application development!
While this documentation is expected to grow considerably over time it already provides solid group for developers to begin creating GRIDNET OS UI dApps of their own. Make sure to check regularly for updated contents. We employ a backwards compatibility paradigm thus anything you find is is very likely to remain active in any future updated to the APIs.
GRIDNET OS VM Context Documentation
GRIDNET OS VM Context, or `CVMContext`, is the pivotal JavaScript component made available through the GRIDNET OS bootloader. It is the central hub through which a user accesses and interacts with various components of GRIDNET OS. This comprehensive document provides details on the unique components and their functionality in the context of the GRIDNET OS.
VMContext, from the developer’s perspective, being the central part of GRDINET OS – offers access to all the sattelite sub-sytems.
The `CVMContext` singleton offers a window into a multitude of systems within the GRIDNET OS:
-
Window Manager
It manages the application windows within the OS.
-
Swarms Manager
Facilitates cross-browser communication.
-
GRIDNET Meta Data Protocol Serializers and De-serializers
Crucial for data serialization between full nodes, web-browsers, and mobile apps.
-
Processes and Threads Abstraction
Allows handling of processes and threads within the OS.
-
State Less Channels' Manager
Manages off-the-chain transactions.
-
File System
Provides a structure for storing and organizing files.
-
QR Intents
Mechanism for displaying QR codes for user authorization.
-
User Session Management
Oversees user sessions within the GRIDNET OS.
-
Core Nodes Connection Management
Handles connections with GRIDNET Core nodes.
-
Peer Discovery
Allows the discovery of other peer nodes in the network.
-
GRIDNET Threads Management
Manages and schedules GRIDNET Threads within the browser and Core nodes.
-
Consensus Tasks' Framework
Tracks pending consensus operations that affect the decentralized state machine. Consensus tasks are represented by instances of `CConsensusTask`.
-
User Interface Tasks' Framework
Handles user interface tasks, represented by `CGUITask`.
-
Low-Level Networking Framework
Facilitates command dispatchment directly to Core Nodes.
-
Mobile App Framework
Allows users to dispatch tasks, events, and notifications to the GRIDNET Token mobile app.
-
Thread Commits' Mechanics
Ensures proper synchronization and access of UI Dapps to the decentralized processing threads.
Developers can always retrieve an instance of `CVMContext` using `CVMContext.getInstance()`. This instance provides access to all the mentioned components. The current status of the `CVMContext` is indicated by the first virtual LED in the GRIDNET’s Virtual Status LED UI component. The architecture of VM Context is event-driven. This architecture gives developers the flexibility to sign up for and handle appropriate events, allowing them to plug into any processing pipeline within the GRIDNET OS.
Components such as the Window Manager are accessible through dedicated objects. However, they are also always available from `CVMContext`. This consistency of access makes it easier to develop decentralized applications using GRIDNET OS. `CVMContext` plays a significant role as a central hub for developers working on decentralized applications. It provides access to a wide range of components and functionality, and its event-driven architecture allows for a high degree of flexibility and customizability. Detailed API documentation will follow in the subsequent sections, providing further insight into how to leverage the power of `CVMContext` and its associated components.
Here is the breakdown of the `CVMContext` constructor:
constructor(...nodeURIs)
The constructor accepts an arbitrary number of node URIs. This means you can initialize the `CVMContext` with one or more IP addresses of the GRIDNET Core nodes. These URIs are collected into an array named `nodeURIs`.
In the body of the constructor, numerous properties are initialized with their default values. Some notable ones include:
- mWasConnected, `mFirstConnectionAttempt`, and `mRecentNetMsgSrcSeq` that store connection-related information.
- mPublicIPAddress is set to localhost by default, i.e., “127.0.0.1”.
- mControllerThreadInterval sets the interval at which the controller thread runs.
- mJSThreads is an empty array that will later hold the JavaScript threads.
- mCommitLockTime specifies the pre-lock duration before the actual lock is made.
The constructor also sets up numerous event listeners arrays such as `mNewNetMsgListeners`, `mNewDFSMsgListeners`, `mOperationStatusListeners`, `mVMStateChangedListeners` etc. These will be used to subscribe and react to various events within the system.
Towards the end of the constructor, several instances of different services are created:
- mSwarmManager for managing swarms.
- mChannelsManager for managing stateless channels.
- mLocalDataStore for local data storage.
- mCryptoFactory for cryptographic operations.
- mMetaParser and `mMetaGenerator` for handling metadata.
- mFileSystem for file system operations.
Finally, if no URIs were provided in the constructor, an error message is logged and the constructor returns early.
if (nodeURIs == null || nodeURIs.length == 0) {
console.log("Fatal Error: No full-nodes' IP addresses were provided. You need to re-initialize the ⋮⋮⋮ Context.");
return;
}
The URIs are stored in the `mAvailableNodeUris` property and will be used for connecting to the GRIDNET Core nodes. The VM Context takes care of the connection and reconnection to these nodes autonomously. Thus, a user or developer does not need to manually manage these connections, making the interaction with the system more efficient.
Methods
-
-
processGridScript(cmd,threadID, processHandle, mode, reqID)
– Parameters:
1. `cmd`: (Type: String) This is the GridScript command that is to be processed.
2. `threadID`: (Type: ArrayBuffer) This is an optional parameter with a default value of an empty ArrayBuffer. It is the ID of the decentralized thread which is to process the command. If no threadID is provided, instructions would be processed by the main decentralized thread associated with the current connection.
3. `processHandle`: (Type: Object) This is a handle to the user-mode process that is calling this function. It is required because anonymous calls to this function are not allowed.
4. `mode`: (Type: eVMMetaCodeExecutionMode, an enumeration) This is an optional parameter with a default value of `eVMMetaCodeExecutionMode.RAW`. It dictates the mode in which the GridScript is to be processed.
5. `reqID`: (Type: Integer) This is an optional parameter with a default value of 0. It is the request identifier for tracking the execution status of the command.
– Returns: (Type: Boolean) This method returns a boolean value which is the result of the call to the `processGridScriptKM()` method.
– Use Case: The `processGridScript()` method of the `CVMContext` class is an asynchronous, user-mode method that allows for processing arbitrary GridScript instructions. This method ensures that only authenticated processes (non-anonymous) can invoke GridScript processing. If a `processHandle` is not provided or is not a valid process, an error message is logged, and the method returns `false`. If the `processHandle` is valid, it forwards the command for processing to the `processGridScriptKM()` method.
– Use Case: This function is used when a process in the system needs to execute GridScript instructions. It offers a way to run commands in a specific thread within the process’s context. This is particularly useful for multi-threaded applications running in a decentralized environment where thread management and script execution control are required. The function can be used to execute various tasks or computations using GridScript, which is a command-based script language for the system. -
genRequestID()
– Parameters: None
– Returns: A number which represents the new request ID incremented by one from the most recent request ID.
– Use Case: This function could be used to generate a unique ID for each new request, helping to keep track of multiple requests, their states and results. -
getPackageID()
– Parameters: None
– Returns: A string “org.gridnetproject.UIdApps.magicButton” that represents the ID of the package.
– Use Case: This static method can be used to fetch the package ID, which can be useful in package management, version tracking, and application identification. -
get getPackageID()
– Parameters: None
– Returns: The package ID if defined; otherwise, ‘unknown’.
– Use Case: This getter method can be used to retrieve the package ID from an instance of the class. This could be used to verify the package origin or determine the functionality of the package. -
get getProcessID()
– Parameters: None
– Returns: A constant value of 1, indicating the process ID.
– Use Case: This getter can be used to retrieve the process ID, which can be useful when managing multiple processes and identifying specific ones for operations such as process termination, monitoring, or resource allocation. -
getThreadByID(id)
– Parameters: `id` – A numeric or string ID of the thread to be retrieved.
– Returns: Thread if found, else null.
– Use Case: This function can be used to retrieve a thread by its ID. This is useful in multithreading environments where a specific thread needs to be manipulated or its state needs to be checked. -
getInstance(...nodeURIs)
– Parameters: `…nodeURIs` – A variable number of parameters that represent node URIs.
– Returns: An instance of CVMContext.
– Use Case: This function ensures the Singleton pattern, allowing only one instance of CVMContext to be created. It can be useful to maintain the state and control the instantiation of CVMContext.
-
Please let me know when you’re ready to continue with the rest of the methods, accessors, and setters.
-
-
getNewProcessID()
– Parameters: None
– Returns: A new user-mode process ID, incremented by one from the most recent user-mode process ID.
– Use Case: This function is used for creating a unique identifier for each new user-mode process, allowing for individual process tracking and manipulation. -
createJSThread(funcPtr, processID = 0, intervalMS = 1000, autoRun = true, isKernelMode = false)
– Parameters:
– `funcPtr`: A function pointer that defines the behaviour of the thread.
– `processID`: A number that represents the ID of the process that this thread belongs to. Default is 0.
– `intervalMS`: A number that defines the interval between each execution of the thread in milliseconds. Default is 1000.
– `autoRun`: A boolean that indicates whether the thread should automatically start running upon creation. Default is true.
– `isKernelMode`: A boolean that indicates whether the thread is running in kernel mode. Default is false.
– Returns: The identifier of the newly created JavaScript thread.
– Use Case: This method can be used to create a new JavaScript thread with specific configurations. This is useful for managing concurrent tasks or processes. -
stopJSThread(threadID)
– Parameters: `threadID` – The identifier of the JavaScript thread to be stopped.
– Returns: The result of stopping the JavaScript thread.
– Use Case: This method can be used to stop a running JavaScript thread. This is crucial for managing resources and maintaining the performance of the system. -
getNewThreadID(isKernelMode)
– Parameters: `isKernelMode` – A boolean indicating if the process is running in kernel mode.
– Returns: A new user-mode process ID or kernel-mode process ID based on the provided boolean argument.
– Use Case: This method is used when creating a new thread for either user-mode or kernel-mode processes. The distinction is necessary as kernel-mode threads have privileges that user-mode threads do not. -
set setCommitState(state)
– Parameters: `state` – The desired state to set.
– Returns: None.
– Use Case: This setter is used to define the state of a commit. This is particularly useful in managing the lifecycle of transactions within the context. -
get getCommitState()
– Parameters: None.
– Returns: The current state of the commit.
– Use Case: This getter method allows for the retrieval of the current commit state. This is crucial in understanding the status of a commit operation. -
get getSystemThreadID()
– Parameters: None.
– Returns: The system thread ID.
– Use Case: This method retrieves the ID of the system thread. This information is essential in tracking and managing system-level threads. -
set setDataThreadID(id)
– Parameters: `id` – The ID to set as the data thread ID.
– Returns: None.
– Use Case: This setter allows for the definition of a data thread ID. This can be used for tracking or managing a particular thread related to data processing. -
get getDataThreadID()
– Parameters: None.
– Returns: The data thread ID.
– Use Case: This method allows for the retrieval of the data thread ID. This ID is crucial for any operations or actions that need to be performed on the data thread. -
get getGamingModeEnabled()
– Parameters: None.
– Returns: A boolean indicating if the gaming mode is enabled or not.
– Use Case: This getter checks if the system is currently in gaming mode, providing relevant information for system settings or user interface changes. -
get getTotalPendingOutgressTransfer()
– Parameters: None.
– Returns: The total pending outgoing data transfer.
– Use Case: This getter method is used when you need to check the amount of data that is currently pending to be sent out from the system. This can be helpful in managing network resources and bandwidth. -
incTotalPendingOutgressTransfer(value)
– Parameters: `value` – The value by which to increase the total pending outgoing data transfer.
– Returns: None.
– Use Case: This method increases the total pending outgoing data transfer by the provided value. This can be used when new data is added to the outgoing queue. -
decTotalPendingOutgressTransfer(value)
– Parameters: `value` – The value by which to decrease the total pending outgoing data transfer.
– Returns: None.
– Use Case: This method decreases the total pending outgoing data transfer by the provided value. This can be used when some data has been sent out, and the pending data amount needs to be reduced. -
clearTotalPendingOutgressTransferValue()
– Parameters: None.
– Returns: None.
– Use Case: This method clears the total pending outgoing data transfer. This can be used when all data has been sent and the pending queue is now empty. -
get getDNS()
– Parameters: None.
– Returns: The DNS sub-system.
– Use Case: This getter method is used to retrieve the DNS sub-system. This is important when needing to perform operations related to the DNS. -
getNewNetMsgSrcSeq()
– Parameters: None.
– Returns: Source sequence number of a new CNetMsg container.
– Use Case: This method is used to generate a source sequence number for a new network message container. It is useful when creating new network messages. -
getNewSDPMsgSrcSeq()
– Parameters: None.
– Returns: Source sequence number of new CSDPMsg containers.
– Use Case: This method is similar to the previous, but for Secure Data Packet (SDP) messages. It’s used in the creation of new SDP messages in the Swarms API. -
get ICEServers()
– Parameters: None.
– Returns: ICEServers for WebRTC.
– Use Case: When establishing a WebRTC connection, you need to get a list of ICEServers. This method provides that information. -
getProcessByID(id)
– Parameters: `id` – The ID of the process.
– Returns: The process corresponding to the provided ID.
– Use Case: This is used when you need to fetch a specific process by its ID. -
setICENodes(nodes)
– Parameters: `nodes` – A collection of ICENodes.
– Returns: None.
– Use Case: This method is used to set ICENodes for WebRTC connections. It allows the user to establish connections with other nodes. -
getICENodes(nodes)
– Parameters: `nodes` – A collection of ICENodes.
– Returns: The requested ICENodes.
– Use Case: This method is used to get ICENodes for WebRTC connections. It allows the user to fetch connections with other nodes. -
addICENode(node)
– Parameters: `node` – An ICENode.
– Returns: None.
– Use Case: This method is used to add a single ICENode for WebRTC connections. -
setProxyNodes(nodes)
– Parameters: `nodes` – A collection of proxy nodes.
– Returns: None.
– Use Case: This method is used to set a list of proxy nodes that can be used to route traffic. -
getProxyNodes(nodes)
– Parameters: `nodes` – A collection of proxy nodes.
– Returns: The requested proxy nodes.
– Use Case: This method is used to get a list of proxy nodes that can be used to route traffic. -
addProxyNode(node)
– Parameters: `node` – A proxy node.
– Returns: None.
– Use Case: This method is used to add a single proxy node to the list of nodes that can be used to route traffic. -
getProcessByThreadID(id)
– Parameters: `id` – A thread ID.
– Returns: The process that owns the thread specified by the given identifier.
– Use Case: This method is used to find the process that owns a specific thread. This can be useful for managing or debugging processes and threads in a system. -
registerProcessByWinHandle(windowHandle)
– Parameters: `windowHandle` – The handle to a window.
– Returns: None.
– Use Case: This method is used to register a process provided a window handle. This could be useful in a GUI application where processes are linked with specific windows. -
unregisterProcess(processID)
– Parameters: `processID` – The ID of the process to be unregistered.
– Returns: None.
– Use Case: This method is used to unregister a process using its ID. It’s useful in managing resources and maintaining the state of the system. -
get getSettingsManager()
– Parameters: None.
– Returns: The Settings Manager.
– Use Case: This method is used to get access to the Settings Manager. This can be used to change or query the system settings. -
get getSessionKey()
– Parameters: None.
– Returns: The session key established for communication with the current node.
– Use Case: This method is used to get the session key that is used for secure communication with the current node. -
get getRemoteSessionDescription()
– Parameters: None.
– Returns: The remote session description.
– Use Case: This method is used to get the description of the remote session. This might include details like the status of the session, the other node’s details, etc. -
logAppEvent(info, process = null, entryType = eLogEntryType.notification, priority = 1)
– Parameters:
– `info` – Information about the event.
– `process` (Optional) – The process related to the event.
– `entryType` (Optional) – The type of the log entry.
– `priority` (Optional) – The priority level of the log entry.
– Returns: None.
– Use Case: This method is used to log application events, which can be useful for auditing or debugging purposes. -
set setRemoteSessionDescription(desc)
– Parameters: `desc` – The remote session description.
– Returns: None.
– Use Case: This method is used to set the description of the remote session. This might include details like the status of the session, the other node’s details, etc. -
get getUserSessionDescription()
– Parameters: None.
– Returns: The user’s session description.
– Use Case: This method returns the user’s session description. This could be used to manage sessions and provide personalized content or features to the user. -
requestQRLogon()
– Parameters: None.
– Returns: None.
– Use Case: This method initiates a QR Code based user login procedure. A QR code would be rendered on the screen, which the user needs to scan with their GRIDNET Token mobile app. It’s useful in providing a secure login option. -
get getUserID()
– Parameters: None.
– Returns: The user’s ID.
– Use Case: This method returns the user’s ID. This could be used to uniquely identify users, for purposes like managing sessions, personalizing content, etc. -
set setUserID(userID)
– Parameters: `userID` – The user’s ID to be set.
– Returns: None.
– Use Case: This method sets the user’s ID. This could be used during registration or when updating a user’s information. -
get getUserFullID()
– Parameters: None.
– Returns: The user’s full ID.
– Use Case: This method returns the user’s full ID. This could be used to uniquely identify users, for purposes like managing sessions, personalizing content, etc. -
get getSwarmsManager()
– Parameters: None.
– Returns: The Swarms Manager.
– Use Case: This method returns the Swarms Manager. This could be used to manage and control swarms of processes or threads. -
get getDataStore()
– Parameters: None.
– Returns: The Data Store.
– Use Case: This method returns the Data Store. This could be used to manage and access data stored by the application. -
isPeerBlackListed(peerID)
– Parameters: `peerID` – The identifier of a peer to check.
– Returns: Returns a boolean indicating whether a peer with the provided ID is blacklisted.
– Use Case: This method is used when there is a need to verify if a particular peer has been blacklisted, e.g., to avoid communication or transactions with peers known to be problematic or harmful. -
get getUserTokenPools()
– Parameters: None.
– Returns: Returns multi-dimensional token pools associated with the user’s account.
– Use Case: This method is used to access the multiple token pools associated with a user’s account. These could be used for various functionalities like managing access, handling transactions, etc., depending on the application. -
get getLoggingEnabled()
– Parameters: None.
– Returns: A boolean indicating whether logging is enabled.
– Use Case: This method is used to check if logging is currently enabled. It can be used in scenarios where specific operations should only be carried out if logging is enabled, or to adjust the level of detail provided in logs. -
set setLoggingEnabled(doIt)
– Parameters: `doIt` – A boolean value to set whether logging should be enabled.
– Returns: None.
– Use Case: This method is used to enable or disable logging. This can be useful for development or debugging scenarios, or to control the amount of storage used by logs. -
set setLogVMStatus(doIt)
– Parameters: `doIt` – A boolean value to set whether logging of VM status should be enabled.
– Returns: None.
– Use Case: This method is used to enable or disable logging of the VM status. This can be useful for debugging or monitoring the state of the VM. -
set setLogAppEvents(doIt)
– Parameters: `doIt` – A boolean value to set whether logging of app events should be enabled.
– Returns: None.
– Use Case: This method is used to enable or disable logging of app events. This can be useful for debugging, user behaviour analysis, or event tracking. -
set setLogTerminalPackets(doIt)
– Parameters: `doIt` – A boolean value to set whether logging of terminal packets should be enabled.
– Returns: None.
– Use Case: This method is used to enable or disable logging of terminal packets. This can be useful for network diagnostics or troubleshooting. -
get getLogNetPackets()
– Parameters: None.
– Returns: A boolean indicating whether the logging of network packets is enabled or not.
– Use Case: This method is used to check if the logging of network packets is currently enabled. This could be important for network debugging or monitoring network activity. -
set setLogNetPackets(doIt)
– Parameters: `doIt` – A boolean value indicating whether logging of network packets should be enabled or disabled.
– Returns: None.
– Use Case: This method is used to enable or disable the logging of network packets. It could be useful for diagnosing network issues or tracking network usage. -
get getLogVMmeta()
– Parameters: None.
– Returns: This method returns a value (presumably a boolean or object), but its exact return value is not specified in the provided code.
– Use Case: This method is presumably used to retrieve metadata about the logging status of the VM. This could be useful for monitoring or debugging the VM. -
commit(appHandle = null, breakLock = false, threadID = 'system')
– Parameters:
– `appHandle` – A handle to the app. Default is null.
– `breakLock` – A boolean indicating whether to break the commit lock or not. Default is false.
– `threadID` – The ID of the thread. Default is ‘system’.
– Returns: This method presumably performs a commit operation, but its exact return value is not specified in the provided code.
– Use Case: This method is used to attempt the commit procedure for multiple decentralized processing threads. This would be used when changes made in the local version of the data need to be updated to the network version of the data. -
get getIsCommiting()
– Parameters: None.
– Returns: A boolean indicating whether a commit operation is currently in progress.
– Use Case: This getter method is typically used to check if a commit operation is currently taking place. This can be useful in managing operations that depend on the completion of commit processes. -
set setIsCommiting(isIt)
– Parameters: `isIt` – A boolean indicating whether a commit operation is taking place.
– Returns: None.
– Use Case: This setter method is typically used to mark the start or end of a commit operation. This can be useful for tracking the status of commit processes and ensuring the system’s state is correctly updated. -
notifyMobileToken(status, scope = eOperationScope.peer, reqID = 0, ID = new ArrayBuffer(), allowUnconfirmedUserSession = false)
– Parameters:
– `status`: Status message to deliver to the mobile token.
– `scope`: The scope of the operation. Default is `eOperationScope.peer`.
– `reqID`: ID for the request. Default is 0.
– `ID`: Array buffer that presumably holds the ID for the message. Default is an empty array buffer.
– `allowUnconfirmedUserSession`: Boolean flag that allows an unconfirmed user session. Default is false.
– Returns: Not specified in the provided code, but it presumably sends a status notification to a mobile token.
– Use Case: This method is used to send a status notification to a mobile app through onion routing. It’s useful for securely updating the status of an operation to the user on their mobile device. -
notifyOperationStatus(status, scope, reqID = 0, ID = new ArrayBuffer(), destination = new ArrayBuffer(), destinationType = eEndpointType.IPv4)
– Parameters:
– `status`: Status message to deliver.
– `scope`: The scope of the operation.
– `reqID`: ID for the request. Default is 0.
– `ID`: Array buffer that presumably holds the ID for the message. Default is an empty array buffer.
– `destination`: The destination for the status message. Default is an empty array buffer.
– `destinationType`: The type of the destination endpoint. Default is `eEndpointType.IPv4`.
– Returns: Not specified in the provided code, but it presumably notifies the status of an operation to a specific destination.
– Use Case: This method is an utility function to deliver the status of an operation to either a full node or a mobile app routed through the full-node. It is useful for securely updating the status of an operation. -
syncVMKF(breakCommit = false, processHandle = null, scopeSystemThreadP = true)
– Parameters:
– `breakCommit`: A boolean indicating if any pending commit should be broken. Default is `false`.
– `processHandle`: The handle for the process. Default is `null`.
– `scopeSystemThreadP`: A boolean indicating the scope of the system thread. Default is `true`.
– Returns: Not specified in the provided code, but it presumably synchronizes the VM context with the current state of the Decentralized VM.
– Use Case: This kernel-mode function is used to ensure the VM context matches the current state of the Decentralized VM. It’s useful in situations where the consistency of the system is critical, such as during transaction processing or system updates. -
syncVM(breakCommit = false, processHandle = null)
– Parameters:
– `breakCommit`: A boolean indicating if any pending commit should be broken. Default is `false`.
– `processHandle`: The handle for the process. Default is `null`.
– Returns: Not specified in the provided code, but it presumably synchronizes the VM context with the rest of the network.
– Use Case: This method is used to ensure that the VM context is in sync with the rest of the network. It is typically invoked during network operations where it’s essential that the VM context mirrors the current network state. -
enterFullscreen()
– Parameters: None.
– Returns: Not specified in the provided code, but it presumably forces the UI to enter full-screen mode.
– Use Case: This method can be used to ensure maximum screen space for the application. It can be particularly useful for UI-intensive applications or games where it’s essential to utilize as much screen real estate as possible. -
exitFullscreen()
– Parameters: None.
– Returns: Not specified in the provided code, but it presumably forces the UI to exit full-screen mode.
– Use Case: This method is used when the application no longer needs to occupy the entire screen. This can be useful in situations where the user needs to interact with other applications or windows on their device. -
initVM(breakCommit = true)
– Parameters: `breakCommit` – A boolean indicating if any pending commit should be broken. Default is `true`.
– Returns: Not specified in the provided code, but it presumably forces the main decentralized processing thread to be initialized.
– Use Case: This method is typically used to initialize the main decentralized processing thread. It’s usually invoked at the start of an application or when starting a new processing task. -
initDTI(instanceID = 0, threadID = new ArrayBuffer())
– Parameters:
– `instanceID`: An identifier for the instance. Default is `0`.
– `threadID`: An ArrayBuffer containing the identifier for the thread.
– Returns: Not specified in the provided code, but it presumably initializes a decentralized Terminal Interface.
– Use Case: This method is used when initializing a decentralized Terminal Interface (DTI). A DTI could be useful in applications where a terminal-based interface is preferred or needed, such as command line tools, server applications, or applications running on devices with limited graphical capabilities. -
sendKeyStroke(keyCode = 13, processID = 0, threadID = new ArrayBuffer())
– Parameters:
– `keyCode` (Number): The unicode of the keyboard key. The default is `13` (Enter key).
– `processID` (Number): The ID of the process invoking this method. Default is `0`.
– `threadID` (ArrayBuffer): The buffer containing thread identifier. Default is a new ArrayBuffer.
– Return: Not provided.
– Description: This method sends key strokes to a Decentralized Terminal Interface (DTI) maintained by a node the user is connected to. It can target a specific decentralized processing thread. Useful for programmatically simulating key presses within a given process context.
– Use Case Scenario: Let’s say there’s a script running in a decentralized processing thread that’s waiting for a specific key stroke to proceed. This method can be used to provide that key stroke, triggering the script to continue its execution. -
sendLine(line = '\r\n', processID = 0)
– Parameters:
– `line` (String): The line to send. Default is `\r\n` (carriage return and newline).
– `processID` (Number): The ID of the process invoking this method. Default is `0`.
– Return: Not provided.
– Description: This method sends a line of text to a process in the Decentralized Terminal Interface (DTI). Useful for providing input to a process or triggering specific line-based events.
– Use Case Scenario: If a running process is waiting for a specific command to be entered line by line, this method can be used to provide that command programmatically. -
sendTerminalDimensions(height, width, processID = 0)
– Parameters:
– `height` (Number): The height of the terminal.
– `width` (Number): The width of the terminal.
– `processID` (Number): The ID of the process invoking this method. Default is `0`.
– Return: Not provided.
– Description: This method sends dimensions of a virtual terminal interface associated with a UI dAPP. Useful for adapting the interface to changes in terminal dimensions.
– Use Case Scenario: If a dAPP’s user interface has been resized, this method can be used to update the dimensions of the associated terminal to ensure that output is displayed correctly. -
unregisterEventListenersByAppID(appID)
– Parameters:
– `appID` (Number): The identifier for the app whose event listeners are to be unregistered.
– Return: Not provided.
– Description: This method unregisters all the event listeners associated with the specified app. This is useful when an app is no longer active or when it needs to reset its event listeners.
– Use Case Scenario: If an app is being unloaded or its event handling needs are changing, this method can be used to remove all of its current event listeners to avoid unnecessary processing or incorrect behavior. -
refreshConsensusTaskIfPresent(task)
– Parameters:
– `task` (Object): The consensus task to refresh.
– Return: Not provided.
– Description: This method refreshes a specified consensus task if it exists. This can be helpful to ensure that the state of the task is up-to-date in the context of decentralized processing.
– Use Case Scenario: If there are changes that may affect the status or result of a consensus task, this method can be used to refresh the task and make sure it reflects the current state of the network. -
addConsensusTask(task, isLocal = true)
– Parameters:
– `task` (Object): The consensus task to add.
– `isLocal` (Boolean): Indicates if the task was formulated locally. Default is `true`.
– Return: Not provided.
– Description: This method adds a consensus task to the list of tasks. It indicates whether the task was formulated locally or delivered from the network.
– Use Case Scenario: When a new consensus task has been created, whether locally or through network communication, this method can be used to add it to the list of tasks to be processed. -
getConsensusTaskByDescription(description = '', subDescription = null)
– Parameters:
– `description` (String): The main description of the consensus task to fetch.
– `subDescription` (String): The sub-description of the consensus task to fetch.
– Return: Not provided.
– Description: This method retrieves a consensus task by its main and sub-description. If no sub-description is provided, it searches using only the main description.
– Use Case Scenario: If a specific consensus task needs to be retrieved based on its descriptive details, this method can be used to locate and retrieve it. -
clearPendngConsensusTasks()
– Parameters: None.
– Return: Not provided.
– Description: This method clears all pending consensus tasks. This can be useful when the current list of tasks is no longer relevant or valid.
– Use Case Scenario: If the system encounters an error or changes in a way that invalidates the current pending consensus tasks, this method can be used to clear them and start fresh. -
get getConsensusTasksCount()
– Parameters: None.
– Return: The count of current consensus tasks.
– Description: This getter method retrieves the current count of consensus tasks.
– Use Case Scenario: When needing to understand the volume of consensus tasks currently in queue, this method provides a quick numerical answer. -
get getConsensusTasks()
– Parameters: None.
– Return: The list of current consensus tasks.
– Description: This getter method retrieves the current list of consensus tasks.
– Use Case Scenario: When needing to examine the actual consensus tasks in the queue, this method provides the full list. -
addDFSRequestCompletedListener(eventListener, appID = 0)
– Parameters:
– `eventListener` (Function): The callback function to be invoked when a DFS (Decentralized File System) request is completed.
– `appID` (Number): The identifier for the application. Default is 0.
– Return: Not provided.
– Description: This method adds an event listener for completed DFS requests. Whenever a DFS request completes, the provided `eventListener` function is called.
– Use Case Scenario: In a decentralized file sharing system, where applications need to know when a file transfer or request has completed, this method allows an application to register a callback to be notified when such an event occurs. -
addUserNotificationsListener(eventListener, appID = 0)
– Parameters:
– `eventListener` (Function): The callback function to be invoked when a user notification event occurs.
– `appID` (Number): The identifier for the application. Default is 0.
– Return: Not provided.
– Description: This method adds an event listener for user notifications. The provided `eventListener` function is called whenever a user notification event occurs.
– Use Case Scenario: In an application that needs to respond to user notifications (for instance, updates, alerts or messages), this method allows the application to register a callback to be triggered upon receiving such notifications. -
addVMMetaDataListener(eventListener, appID = 0)
– Parameters:
– `eventListener` (Function): The callback function to be invoked when VM (Virtual Machine) metadata changes.
– `appID` (Number): The identifier for the application. Default is 0.
– Return: Not provided.
– Description: This method adds an event listener for changes in VM metadata. The provided `eventListener` function is called whenever VM metadata changes.
– Use Case Scenario: In a scenario where applications need to respond to changes in VM metadata (such as resource usage or state changes), this method allows an application to register a callback to be triggered when such changes occur. -
addNewGridScriptResultListener(eventListener, appID = 0)
– Parameters:
– `eventListener` (Function): The callback function to be invoked when a new GridScript result is available.
– `appID` (Number): The identifier for the application. Default is 0.
– Return: Not provided.
– Description: This method adds an event listener for new GridScript results. The provided `eventListener` function is called whenever a new GridScript result becomes available.
– Use Case Scenario: In a system where applications run GridScripts and need to respond to their results, this method allows an application to register a callback to be notified when new results are available. -
addNewTerminalDataListener(eventListener, appID = 0)
– Parameters:
– `eventListener` (Function): The callback function to be invoked when new terminal data is available.
– `appID` (Number): The identifier for the application. Default is 0.
– Return: Not provided.
– Description: This method adds an event listener for new terminal data. The provided `eventListener` function is called whenever new terminal data becomes available.
– Use Case Scenario: In an application where terminal interactions are important (e.g., CLI based applications, SSH clients, etc.), this method allows the application to register a callback to be notified when new terminal data is available. -
addNewAppDataListener(eventListener, appID = 0)
– Parameters:
– `eventListener` (Function): The callback function to be invoked when new application data is available.
– `appID` (Number): The identifier for the application. Default is 0.
– Return: Not provided.
– Description: This method adds an event listener for new application data. The provided `eventListener` function is called whenever new application data becomes available.
– Use Case Scenario: In an application that needs to respond to changes in its own data (like state changes, updates, etc.), this method allows the application to register a callback to be triggered when such changes occur. -
addUserLogonListener(eventListener, appID = 0)
– Parameters:
– `eventListener` (Function): The callback function to be invoked when a user logs on.
– `appID` (Number): The identifier for the application. Default is 0.
– Return: Not provided.
– Description: This method adds an event listener for user logon events. The provided `eventListener` function is called whenever a user logs on.
– Use Case Scenario: In an application that needs to respond to user logon events (like displaying personalized content, logging user activities, etc.), this method allows the application to register a callback to be triggered when a user logs on. -
addUserActionRequestListener(eventListener, appID = 0)
– Parameters:
– `eventListener` (Function): The callback function to be invoked when a user action request occurs.
– `appID` (Number): The identifier for the application. Default is 0.
– Return: Not provided.
– Description: This method adds an event listener for user action requests. The provided `eventListener` function is called whenever a user action request occurs.
– Use Case Scenario: In an application that needs to respond to user action requests (like responding to user inputs, changing interface based on user requests, etc.), this method allows the application to register a callback to be triggered when such requests occur. -
addNewKeyBlockListener(eventListener, appID = 0)
– Parameters:
– `eventListener` (Function): The callback function to be invoked when a new key block is available.
– `appID` (Number): The identifier for the application. Default is 0.
– Return: Not provided.
– Description: This method adds an event listener for new key blocks. The provided `eventListener` function is called whenever a new key block becomes available.
– Use Case Scenario: In a blockchain application that needs to respond to the arrival of new key blocks (for example, to validate them, update local storage, etc.), this method allows the application to register
-
a callback to be triggered when a new key block arrives.
-
addNewConsensusActionListener(eventListener, appID = 0)
– Parameters:
– `eventListener` (Function): The callback function to be invoked when a new consensus action occurs.
– `appID` (Number): The identifier for the application. Default is 0.
– Return: Not provided.
– Description: This method adds an event listener for new consensus actions. The provided `eventListener` function is called whenever a new consensus action occurs.
– Use Case Scenario: In a system where applications need to respond to consensus actions (such as in a blockchain or a distributed ledger system), this method allows an application to register a callback to be notified when a new consensus action occurs. -
addNewDataBlockListener(eventListener, appID = 0)
– Parameters:
– `eventListener` (Function): The callback function to be invoked when a new data block is available.
– `appID` (Number): The identifier for the application. Default is 0.
– Return: Not provided.
– Description: This method adds an event listener for new data blocks. The provided `eventListener` function is called whenever a new data block becomes available.
– Use Case Scenario: In a blockchain application that needs to respond to the arrival of new data blocks (for example, to validate them, update local storage, etc.), this method allows the application to register a callback to be triggered when a new data block arrives. -
addVMStateChangedListener(eventListener, appID = 0)
– Parameters:
– `eventListener` (Function): The callback function to be invoked when the state of a VM (Virtual Machine) changes.
– `appID` (Number): The identifier for the application. Default is 0.
– Return: Not provided.
– Description: This method adds an event listener for changes in the state of a VM, which is associated with a Decentralized Processing Thread (DPT). The provided `eventListener` function is called whenever the VM’s state changes.
– Use Case Scenario: In a decentralized computing environment, where applications are run in separate VMs associated with different DPTs, this method allows an application to register a callback to be notified when the VM’s state changes (e.g., when a task completes or a resource limit is reached). -
addVMCommitStateChangedListener(eventListener, appID = 0)
– Parameters:
– `eventListener` (Function): The callback function to be invoked when the commit state of a VM changes.
– `appID` (Number): The identifier for the application. Default is 0.
– Return: Not provided.
– Description: This method adds an event listener for changes in the commit state of a VM, associated with a DPT. The provided `eventListener` function is called whenever the VM’s commit state changes.
– Use Case Scenario: In a decentralized computing environment, applications may need to know when a VM’s commit state changes (e.g., when data is committed or rolled back). This method allows an application to register a callback to be triggered when such changes occur. -
addContextStateChangedListener(eventListener, appID = 0)
– Parameters:
– `eventListener` (Function): The callback function to be invoked when the context state changes.
– `appID` (Number): The identifier for the application. Default is 0.
– Return: Not provided.
– Description: This method adds an event listener for changes in the context state. The provided `eventListener` function is called whenever the context state changes.
– Use Case Scenario: In a decentralized computing environment, applications might need to be notified of context state changes, such as changes in execution environment or system-wide variables. This method allows an application to register a callback to be triggered when such changes occur. -
addNewNetMsgListener(eventListener, appID = 0)
– Parameters:
– `eventListener` (Function): The callback function to be invoked when a new network message is received.
– `appID` (Number): The identifier for the application. Default is 0.
– Return: Not provided.
– Description: This method adds an event listener for new network messages. The provided `eventListener` function is called whenever a new network message is received.
– Use Case Scenario: In a networked application, this method allows an application to register a callback to be notified when a new network message is received, enabling it to respond in real-time to network communications. -
addNewDFSMsgListener(eventListener, appID = 0)
– Parameters:
– `eventListener` (Function): The callback function to be invoked when a new Decentralized File System (DFS) message is received.
– `appID` (Number): The identifier for the application. Default is 0.
– Return: Not provided.
– Description: This method adds an event listener for new DFS messages. The provided `eventListener` function is called whenever a new DFS message is received.
– Use Case Scenario: In a DFS application, this method allows an application to register a callback to be notified when a new DFS message is received, allowing it to respond to changes or updates in the DFS in real-time. -
addOperationStatusListener(eventListener, appID = 0)
– Parameters:
– `eventListener` (Function): The callback function to be invoked when the status of an operation changes.
– `appID` (Number): The identifier for the application. Default is 0.
– Return: Not provided.
– Description: This method adds an event listener for operation status changes. The provided `eventListener` function is called whenever the status of an operation changes.
– Use Case Scenario: In an application that performs operations which might change status over time, this method allows the application to register a callback to be notified when the status of such operations change. -
addNewSwarmSDPMsgListener(eventListener, appID = 0)
– Parameters:
– `eventListener` (Function): The callback function to be invoked when a new Swarm Session Description Protocol (SDP) message is received.
– `appID` (Number): The identifier for the application. Default is 0.
– Return: Not provided.
– Description: This method adds an event listener for new Swarm SDP messages. The provided `eventListener` function is called whenever a new Swarm SDP message is received.
– Use Case Scenario: In a Swarm application, this method allows an application to register a callback to be notified when a new Swarm SDP Message is received. -
addConnectionStatusChangedListener(eventListener, appID = 0)
– Parameters:
– `eventListener` (Function): The callback function to be invoked when connection status changes.
– `appID` (Number): The identifier for the application. Default is 0.
– Return: Not provided.
– Description: This method adds an event listener for connection status changes. The provided `eventListener` function is called whenever the connection status changes.
– Use Case Scenario: An application that requires active network communication may use this method to monitor the status of its connections and respond to any changes accordingly. -
addSessionKeyAvailableListener(eventListener, appID = 0)
– Parameters:
– `eventListener` (Function): The callback function to be invoked when a session key becomes available.
– `appID` (Number): The identifier for the application. Default is 0.
– Return: Not provided.
– Description: This method adds an event listener that triggers when a session key becomes available. The provided `eventListener` function is called in this event.
– Use Case Scenario: In scenarios where secure session communication is needed, this function allows an application to register a callback to be notified when a new session key is available for use. -
setOnScreenLogEnabled(isIt)
– Parameters:
– `isIt` (Boolean): A boolean indicating whether to enable on-screen logging or not.
– Return: Not provided.
– Description: This method enables or disables on-screen logging based on the provided boolean value.
– Use Case Scenario: This function can be used when the developer needs to debug or monitor the system with on-screen logging. -
getOnScreenLogEnabled()
– Parameters: None.
– Return: Boolean indicating whether on-screen logging is enabled or not.
– Description: This method returns the current state of on-screen logging – whether it is enabled or not.
– Use Case Scenario: An application might need to check the status of on-screen logging before making further decisions based on its state. -
attachThreadToProcess(processID, threadID)
– Parameters:
– `processID` (Number): The identifier for the process.
– `threadID` (ArrayBuffer): Identifier for the thread.
– Return: Not provided.
– Description: This method attaches a thread to a process.
– Use Case Scenario: In a multitasking environment, a thread may need to be attached to a specific process for execution. This method facilitates that. -
createThread(threadID, processID = 0)
– Parameters:
– `threadID` (ArrayBuffer): Identifier for the thread.
– `processID` (Number): The identifier for the process. Default is 0.
– Return: Not provided.
– Description: This method requests the system to allocate resources for the initialization of a new decentralized processing thread. The status would be reported during subsequent events.
– Use Case Scenario: In a decentralized computing environment, an application might need to create a new processing thread for handling specific tasks. This function allows the application to make such a request.
35. freeThread(threadID, processID = 0)
– Parameters:
– `threadID` (ArrayBuffer): Identifier for the thread.
– `processID` (Number): The identifier for the process. Default is 0.
– Return: Not provided.
– Description: This method attempts to free a Decentralized Processing Thread identified by the provided thread ID.
– Use Case Scenario: When a thread has completed its task, or is no longer needed, this method can be used to release the resources associated with it, improving the efficiency of the system. -
registerUserDataResponse(response, resetMetaGenerator = true)
– Parameters:
– `response` (Object): The response object to be registered.
– `resetMetaGenerator` (Boolean): Whether to reset the MetaGenerator or not. Default is true.
– Return: Not provided.
– Description: This method registers user data response and optionally resets the MetaGenerator.
– Use Case Scenario: When an application gets a user response, it can register it using this method. Additionally, it can choose to reset the MetaGenerator. -
addNodeURI(URI)
– Parameters:
– `URI` (String): The URI of the Core Node to be added.
– Return: Not provided.
– Description: This method adds the IP address of a Core node that the in-web browser subsystem may use.
– Use Case Scenario: This method is useful when an application needs to add a new Core node to its network for communication. -
getRandomTossedNodeUri()
– Parameters: None.
– Return: URI string of a randomly tossed Core node.
– Description: This method returns the URI of a new core node, presumably before attempting a connection with it.
– Use Case Scenario: When the application needs to connect to a new Core node, this method can be used to get the URI of a randomly selected node. -
getRandomTossedProxyUri()
– Parameters: None.
– Return: URI string of a randomly tossed proxy.
– Description: This method returns the URI of a randomly tossed proxy node.
– Use Case Scenario: When the application needs to connect to a new proxy, this method can be used to get the URI of a randomly selected proxy. -
getClosestNodeUri()
– Parameters: None.
– Return: URI string of the ‘closest’ node based on the current time.
– Description: This method returns the URI of the ‘closest’ node based on the current time.
– Use Case Scenario: This method can be used to get the URI of the closest node when the application needs to reduce latency and improve response time. -
getCurrentNodeURI()
– Parameters: None.
– Return: Returns the URI of the current Node.
– Description: This method provides the URI of the node that the VMContext is currently interacting with.
– Use Case Scenario: An application might want to know the node it is currently interacting with for the purposes of logging, displaying the information to the user, or other operational needs. -
set publicIPAddress(IP)
– Parameters: `IP` (String): The public IP address to be set.
– Return: None.
– Description: Sets the public IP address.
– Use Case Scenario: It can be used to set the IP address of the user’s device for use in communication with the GridNet network. -
get publicIPAddress()
– Parameters: None.
– Return: Returns the set public IP address.
– Description: This method provides the public IP address that was previously set.
– Use Case Scenario: An application may need to retrieve the public IP address of the user’s device for various reasons, such as debugging, logging, or other network-related operations. -
globalErrorHandler(event)
– Parameters: `event` (Event): The error event.
– Return: None.
– Description: Handles global error events.
– Use Case Scenario: This method can be used to define a global error handler for the VMContext. This can be useful for centralized error logging and handling. -
initialize()
– Parameters: None.
– Return: None.
– Description: Logs the initialization of the VMContext.
– Use Case Scenario: This method can be used to kick start the initialization of the VMContext and log the event for debugging or monitoring purposes. -
get getFileSystem()
– Parameters: None.
– Return: Returns the FileSystem instance.
– Description: This method provides an interface to the file system.
– Use Case Scenario: This method can be used to interact with the file system, such as creating, reading, updating, and deleting files. -
get getMagicButton()
– Parameters: None.
– Return: Returns the MagicButton instance.
– Description: This method provides an interface to the MagicButton.
– Use Case Scenario: The MagicButton can perform various functions in the system. This method is used to access these functions. -
get getMetaParser()
– Parameters: None.
– Return: Returns the MetaParser instance.
– Description: This method provides an interface to the MetaParser.
– Use Case Scenario: MetaParser can be used for analyzing and parsing metadata related to VMContext operations. -
get getMetaGenerator()
– Parameters: None.
– Return: Returns the MetaGenerator instance.
– Description: This method provides an interface to the MetaGenerator.
– Use Case Scenario: MetaGenerator is used for creating metadata for VMContext operations. -
get getPackageManager()
– Parameters: None.
– Return: Returns the PackageManager instance.
– Description: This method provides an interface to the PackageManager.
– Use Case Scenario: PackageManager can be used for managing packages related to the VMContext. -
get getWindowManager()
– Parameters: None.
– Return: Returns the WindowManager instance.
– Description: This method provides an interface to the WindowManager.
– Use Case Scenario: WindowManager is used for managing windows within the VMContext, such as creating, closing, and rearranging windows. -
set setConversationID(id)
– Parameters:
– `id`: Identifier for the conversation.
– Return: None.
– Description: Sets the conversation ID for the current VMContext instance.
– Use Case Scenario: When a new conversation starts, this method can be used to set the conversation ID. -
get getConversationID()
– Parameters: None.
– Return: Returns the conversation ID.
– Description: This method returns the ID of the current conversation.
– Use Case Scenario: This method can be used to retrieve the ID of the current conversation. -
get getChannelsManager()
– Parameters: None.
– Return: Returns the ChannelsManager instance.
– Description: This method provides an interface to the ChannelsManager.
– Use Case Scenario: ChannelsManager is used for managing channels related to the VMContext. -
processStateTransition()
– Parameters: None.
– Return: None.
– Description: This function is responsible for transitioning both the Context’s and VM’s reported state. It first reacts to forced-states of internal variables, and then processes the user’s state transition request.
– Use Case Scenario: This function is useful in situations where you need to ensure that the current state is adjusted based on both internal variables and user’s requested transitions. -
processCurrentState()
– Parameters: None.
– Return: None.
– Description: This function carries out routines that are defined for the active State. Depending on the current state, it carries out different operations such as activating the context, managing connection timeouts, managing keep-alive timeouts, etc.
– Use Case Scenario: This function is essential in handling operations that depend on the current active state. -
controllerThreadF()
– Parameters: None.
– Return: None.
– Description: This function is responsible for managing the state of VM-context, connection to a full-node, etc. It processes the state transition and current state in sequence.
– Use Case Scenario: This function is useful in situations where you need to control and manage the state of the VM-context. -
get getFileSystem()
– Parameters: None.
– Return: Returns the FileSystem instance.
– Description: This method provides an interface to the FileSystem.
– Use Case Scenario: FileSystem is used for managing file related operations related to the VMContext. -
genTaskID()
– Parameters: None.
– Return: Presumably generates a unique task ID (however, there’s no code provided).
– Description: This method is meant to generate a unique task ID.
– Use Case Scenario: This method is useful when a unique identifier for a task is required. -
get getState()
– Parameters: None.
– Return: Returns the current state of the VM.
– Description: This method provides an interface to retrieve the current state of the VM.
– Use Case Scenario: This method is used when the current state of the VM is required. -
set setState(state)
– Parameters: `state` – The new state to set.
– Return: None.
– Description: This setter method is used to change the current state of the VM. It also stores the previous state, notifies a state change, and triggers the `notifyContextStateChanged` method.
– Use Case Scenario: This setter is used when there’s a need to change the state of the VM and notify any listeners about this change. -
set setConnectionState(state)
– Parameters: `state` – The new connection state to set.
– Return: None.
– Description: This setter method is used to change the current connection state of the VM. It also stores the previous connection state, processes the new connection state, and triggers the `notifyConnectionStatusChanged` method.
– Use Case Scenario: This setter is used when there’s a need to change the connection state of the VM and notify any listeners about this change. -
processConnectionState(state)
– Parameters: `state` – The new connection state to process.
– Return: None.
– Description: This method processes the new connection state based on its value. It performs various actions such as logging the event, resetting magic button, clearing pending consensus tasks, and processing a disconnect depending on the state.
– Use Case Scenario: This method is used when the connection state has changed and needs to be processed. -
get getConnectionState()
– Parameters: None.
– Return: Returns the current connection state of the VM.
– Description: This method provides an interface to retrieve the current connection state of the VM.
– Use Case Scenario: This method is used when the current connection state of the VM is required. -
get getVMState()
– Parameters: None.
– Return: Returns the current state of the VM.
– Description: This method provides an interface to retrieve the current state of the VM.
– Use Case Scenario: This method is used when the current state of the VM is required. -
set setVMState(state)
– Parameters: `state` – The new VM state to set.
– Return: None.
– Description: This setter method is used to change the current state of the VM. It also stores the previous state and triggers the `notifyVMStateChanged` method.
– Use Case Scenario: This setter is used when there’s a need to change the state of the VM and notify any listeners about this change. -
requstState(state)
– Parameters: `state` – The state requested.
– Return: None.
– Description: This method is used to set a requested state for the VM.
– Use Case Scenario: This method is used when there’s a need to request a state change for the VM. -
doSendText(message)
– Parameters: `message` – The message to be sent.
– Return: None.
– Description: This method sends a text message via the WebSocket connection. The sent message is also logged.
– Use Case Scenario: This method is used whenever there’s a need to send a text message over the WebSocket connection. -
set setCommitTarget(blockchainMode)
– Parameters: `blockchainMode` – The blockchain mode to set.
– Return: None.
– Description: This setter method sets the blockchain mode for the VM.
– Use Case Scenario: This method is used when there’s a need to change the blockchain mode of the VM. -
get getCommitTarget()
– Parameters: None.
– Return: Returns the current blockchain mode of the VM.
– Description: This getter method retrieves the current blockchain mode of the VM.
– Use Case Scenario: This method is used when the current blockchain mode of the VM is required. -
scopeSystemThread(scopeCommitTarget = true, scopeHomeDir = true)
– Parameters: `scopeCommitTarget` (default: true) – Whether to bring the thread under the requested network realm, `scopeHomeDir` (default: true) – Whether to bring the thread under the user’s home State-Domain.
– Return: Returns a boolean value indicating success or failure.
– Description: This method scopes the system thread into the user’s State-Domain, which is necessary for the commits not to fail. If the user is not logged in, this method will return false.
– Use Case Scenario: This method is used when there’s a need to bring the system thread into the user’s State-Domain. -
sendDFSMsg(msg, breakCommit = false, UINotifyOnError = false, doPreProcessing = true)
– Parameters: `msg` – The Distributed File System (DFS) message to be sent, `breakCommit` (default: false) – Whether to break the commit if there’s a pending one, `UINotifyOnError` (default: false) – Whether to notify the user interface on error, `doPreProcessing` (default: true) – Whether to do preprocessing.
– Return: Returns a boolean value indicating success or failure.
– Description: This method sends a DFS message. Before sending, it checks for ongoing commits and if necessary, breaks them. If the message cannot be sent due to errors, the user interface is notified based on the `UINotifyOnError` parameter.
– Use Case Scenario: This method is used when there’s a need to send a DFS message.
73. sendNetMsg(msg, breakCommit = false, UINotifyOnError = false, doPreProcessing = true)
– Parameters: `msg` – The network message to be sent, `breakCommit` (default: false) – Whether to break the commit if there’s a pending one, `UINotifyOnError` (default: false) – Whether to notify the user interface on error, `doPreProcessing` (default: true) – Whether to do preprocessing before sending the message.
– Return: None.
– Description: This method sends a network message. Before sending, it checks for ongoing commits and if necessary, breaks them. If the message cannot be sent due to errors, the user interface is notified based on the `UINotifyOnError` parameter.
– Use Case Scenario: This method is used when there’s a need to send a network message. -
sendBinary(message)
– Parameters: `message` – The binary message to be sent.
– Return: None.
– Description: This method sends a binary message over the network.
– Use Case Scenario: This method is used when there’s a need to send a binary message. -
prepareNetMsg(dataBytes)
– Parameters: `dataBytes` – The data to be sent as a network message.
– Return: Returns a serialized, BER-encoded CNetMsg datagram as an ArrayBuffer.
– Description: This method takes a Decentralized-File-System Command represented as a BER-encoded array and wraps it around a NetMsg container.
– Use Case Scenario: This method is used when there’s a need to prepare a network message from a Decentralized-File-System Command. -
setLogOutputDiv(logDiv)
– Parameters: `logDiv` – The DOM element to which the logs will be output.
– Return: None.
– Description: This method sets the DOM element for log output.
– Use Case Scenario: This method is used when there’s a need to change the location of the log output. -
writeToLog(message, forceIt = false)
– Parameters: `message` – The message to be logged, `forceIt` (default: false) – Whether to forcefully log the message.
– Return: None.
– Description: This method writes a message to the log output.
– Use Case Scenario: This method is used when there’s a need to log a message. -
get getRecentQRIntent()
– Parameters: None.
– Return: Returns the recent QR Intent.
– Description: This getter method retrieves the recent QR Intent.
– Use Case Scenario: This method is used when there’s a need to retrieve the recent QR Intent. -
get getRecentQRIntentTaskID()
– Parameters: None.
– Return: Returns the task ID of the recent QR Intent.
– Description: This getter method retrieves the task ID of the recent QR Intent.
– Use Case Scenario: This method is used when there’s a need to retrieve the task ID of the recent QR Intent. -
get isLoggedIn()
– Parameters: None.
– Return: Returns a boolean value indicating whether the user is logged in or not.
– Description: This getter method checks whether the user is logged in or not.
– Use Case Scenario: This method is used when there’s a need to check whether the user is logged in or not. -
breakCommitLock()
– Parameters: None.
– Return: None.
– Description: This method breaks the commit lock of any pending Decentralized Processing Threads’ Commit procedure. This operation might be necessary in a scenario where there’s a need to interrupt a commit that is taking longer than expected or due to other application specific reasons.
– Use Case Scenario: This method is used when there’s a need to break the commit lock. -
tryLockCommit(appHandle = 0, breakLock = false)
– Parameters: `appHandle` (default: 0) – The handle of the application trying to acquire the lock, `breakLock` (default: false) – Whether to break the existing lock before attempting to acquire it.
– Return: Returns a boolean indicating whether the attempt to lock for commit was successful or not.
– Description: This method tries to acquire the commit lock. If the `appHandle` is provided and it’s the same as the current lock owner, the method returns true. If not, it attempts to take ownership. If `breakLock` is true, it forcefully breaks the existing lock and acquires it. It is crucial that this function is always invoked before sending VM code containing the Commit instruction to prevent race conditions.
– Use Case Scenario: This method is used when there’s a need to lock for commit, or check if a lock for commit could have been acquired. -
markThreadsAsFinalized()
– Parameters: None.
– Return: None.
– Description: This method marks all threads that have data-commits pending as finalized.
– Use Case Scenario: When all threads have completed their tasks and there are no pending data-commits, this function can be called to mark all threads as finalized. -
getUseAEADForSessionKey
– Parameters: None.
– Return: Returns the state of the `mUseAEADForSessionKey` property.
– Description: This getter method fetches the state of AEAD (Authenticated Encryption with Associated Data) usage for the session key.
– Use Case Scenario: When we need to check if AEAD is being used for session key encryption. -
setUseAEADForSessionKey(doIt = true)
– Parameters: `doIt` (default: true) – Whether to use AEAD for session key or not.
– Return: None.
– Description: This setter method sets the state of AEAD (Authenticated Encryption with Associated Data) usage for the session key.
– Use Case Scenario: When we need to change the setting of AEAD usage for session key encryption. -
getUseAEADForAuth
– Parameters: None.
– Return: Returns the state of the `mUseAEADForAuth` property.
– Description: This getter method fetches the state of AEAD (Authenticated Encryption with Associated Data) usage for authentication.
– Use Case Scenario: When we need to check if AEAD is being used for authentication. -
setUseAEADForAuth(doIt = true)
– Parameters: `doIt` (default: true) – Whether to use AEAD for authentication or not.
– Return: None.
– Description: This setter method sets the state of AEAD (Authenticated Encryption with Associated Data) usage for authentication.
– Use Case Scenario: When we need to change the setting of AEAD usage for authentication. -
authAndEncryptMsg(msg, doNotRequireEncryption = false)
– Parameters: `msg` – The message to be authenticated and encrypted, `doNotRequireEncryption` (default: false) – Whether to skip the encryption process or not.
– Return: EncResult on success, and False if anything goes wrong.
– Description: This method authenticates and encrypts a CNetMsg as per the current Conversation’s properties. This function takes care of the authentication and encryption related flags. Any modifications to netmsg afterwards will make its authentication fail.
– Use Case Scenario: When there’s a need to authenticate and encrypt a message. -
getWebSocketSessionID
– Parameters: None.
– Return: Returns the WebSocket session ID.
– Description: This getter method fetches the WebSocket session ID.
– Use Case Scenario: When the WebSocket session ID is needed. -
processVMMetaDataMsg(msg)
– Parameters: `msg` – The VMMetaDataMsg to process.
– Return: Undefined.
– Description: This method processes a VMMetaDataMsg. It does not describe how it processes the message, as that would be specific to the protocol and data fields.
– Use Case Scenario: When there’s a need to process a VMMetaDataMsg. -
forceNode(nodeURI = null)
– Parameters: `nodeURI` (default: null) – The IP address of the node to be forced.
– Return: None.
– Description: This method forces the current main node to be used. If the nodeURI is null, it clears the forced node. If there is an active connection, it is forced to terminate.
– Use Case Scenario: This function is typically used in case you want to force the use of a specific node in your network for some reason. -
clearForcedNode()
– Parameters: None.
– Return: None.
– Description: This method clears the forced node.
– Use Case Scenario: This function is used when you want to clear a previously set forced node. -
getIsEncryptionAvailable()
– Parameters: None.
– Return: Boolean. Returns true if encryption is available.
– Description: This method checks if encryption is available.
– Use Case Scenario: This function is used to verify if encryption is currently available. -
getNodeIP
– Parameters: None.
– Return: Returns the IP address of the current active main node.
– Description: This getter method fetches the IP address of the current active main node.
– Use Case Scenario: When the IP address of the current active main node is needed. -
addGUITask(task, dispatchNotifications = true)
– Parameters: `task` – The GUI task to be added, `dispatchNotifications` (default: true) – Whether to dispatch notifications or not.
– Return: Boolean. Returns false if task is null, true otherwise.
– Description: This method adds a GUI task to a queue. By default, it also dispatches a notification to registered 3rd party extensions.
– Use Case Scenario: This function is used when there is a need to add a GUI task to the queue and potentially dispatch notifications. -
getGUITaskByID(id)
– Parameters: `id` – The ID of the GUI task.
– Return: Returns the GUI task with the specified ID, or null if no such task exists.
– Description: This method fetches a GUI task by its ID.
– Use Case Scenario: When there’s a need to fetch a specific GUI task. -
processGUITask(task)
– Parameters: `task` – The GUI task to process.
– Return: Boolean. Returns false if task is null.
– Description: This method processes a GUI task. The specific behavior is not defined and will depend on the task type.
– Use Case Scenario: When there’s a need to process a specific GUI task.
CGUITask Documentation
Class Name: CGUITask
Description: The `CGUITask` class represents a GUI task that maintains its own state, type, data, and ID.
Properties:
1. mState: The state of the GUI task. This is represented by the `eGUITaskState` enum which can have the following values:
- `initial` (0): The task is in its initial state.
- `enqued` (1): The task has been queued for execution.
- `alreadyShown` (2): The task has already been shown to the user.
- `canceledByUser` (3): The task was cancelled by the user.
- `accomplished` (4): The task has been successfully accomplished.
- `failed` (5): The task failed during execution.
2. mType: The type of the GUI task. This is represented by the `eUITTaskType` enum which can have the following values:
- `notification` (0): The task is a notification.
- `request` (1): The task is a request.
3. mData: The data associated with the GUI task. This could be any data related to the task.
4. mID: The ID of the GUI task. This is generated upon creation of the task.
Methods:
-
constructor(eType, data = null)
Constructs a new GUI task with the provided type and data.
– Parameters:
– `eType`: The type of the task (`eUITTaskType` enum).
– `data` (default: null): The data associated with the task.
- setState(state): Sets the state of the task.
– Parameters:
– `state`: The state to set for the task (`eGUITaskState` enum). - getState: Getter method for the state of the task. It returns the current state of the task.
- getID: Getter method for the ID of the task. It returns the ID of the task.
- getType: Getter method for the type of the task. It returns the type of the task.
- getData: Getter method for the data associated with the task. It returns the data of the task.
Use Case Scenario: The `CGUITask` class can be used whenever there is a need to manage tasks that are to be executed on the GUI. This includes keeping track of the state of each task, the type of task, any data associated with it, and a unique identifier for each task.
enumerations
-
eThreadOperationType
This enumeration represents the possible states of a decentralized processing thread. It includes:
– `newThread` (0): Represents the creation of a new thread.
– `freeThread` (1): Represents a thread that is available for use.
– `threadAliveConfirmation` (2): Represents confirmation that a thread is alive and operational.
– `threadKilledConfirmation` (3): Represents confirmation that a thread has been terminated. -
eContextState
This enumeration is used to describe the state of a `CVMContext`. The possible states include:
– `initial` (0): The context is in its initial state.
– `activating` (1): The context is currently being activated.
– `active` (2): The context is active and operational.
– `inactive` (3): The context is inactive. -
eVMMetaEntryType
This enumeration is used within the VM-Meta Data protocol to depict types of entries. The possible entry types include:
– `unknown` (0)
– `directoryEntry` (1)
– `fileContent` (2)
– `notification` (3)
– `dataRequest` (4)
– `dataResponse` (5)
– `GridScriptCode` (6)
– `GridScriptCodeResponse` (7)
– `terminalData` (8)
– `StateLessChannelsElement` (9)
– `appNotification` (10)
– `VMStatus` (11)
– `threadOperation` (12)
– `consensusTask` (13) -
eVMMetaSectionType
Also used within the VM-Meta Data exchange protocol to depict types of sections. The possible section types include:
– `unknown` (0)
– `directoryListing` (1)
– `fileContents` (2)
– `notifications` (3)
– `requests` (4)
– `stateLessChannels` (5) -
eFSCmdResult
This enumeration represents the possible results of a file system command within a decentralized file system. The possible results include:
– `unknown` (0): The result of the command is unknown.
– `error` (1): The command resulted in an error.
– `invalidCmd` (2): The command is invalid.
– `Ok` (3): The command was successful. -
eFSCommitResult
This enumeration represents the possible outcomes when making a commit to the file system. The possible outcomes include:
– `unknown` (0): The result of the commit is unknown.
– `error` (1): The commit resulted in an error.
– `Ok` (2): The commit was successful. -
eFSEntityType
This enumeration represents the possible types of entities within the file system. The possible entity types include:
– `unknown` (0): The entity type is unknown.
– `file` (1): The entity is a file.
– `dir` (2): The entity is a directory. -
eDFSElementType
This enumeration describes the types of elements within the decentralized file system (DFS). It includes:
– `unknown` (0): The type of the DFS element is unknown.
– `stateDomainEntry` (1): The DFS element is a state domain entry.
– `fileEntry` (2): The DFS element is a file.
– `directoryEntry` (3): The DFS element is a directory.
– `fileContent` (4): The DFS element is the content of a file. -
eDataType
This enumeration represents various data types, compatible with the GridScript 1.0 engine:
– `signedInteger` (0)
– `unsignedInteger` (1)
– `booll` (2): A boolean data type.
– `charr` (3): A character data type.
– `doublee` (4): A double precision floating point number.
– `bytes` (5): A byte array data type.
– `pointer` (6): A pointer data type.
– `noData` (7): No data available.
– `directory` (8): A directory data type.
– `BigInt` (9): A big integer data type.
– `BigSInt` (10): A big signed integer data type.
– `BigDouble` (11): A big double precision floating point number. -
eNotificationType
This enumeration describes types of notifications reported to the user:
– `unknown` (0)
– `notification` (1): A general notification.
– `warning` (2): A warning notification.
– `error` (3): An error notification.
– `binary` (4): A binary notification.
– `copyToClipboard` (5): A command to copy the notification to the clipboard. -
eDFSCmdType
This enumeration describes types of commands issued to the decentralized file-system:
– `unknown` (0)
– `init` (1)
– `ready` (2)
– `error` (3)
– `exists` (4)
– `stat` (5)
– `execute` (6)
– `readDir` (7)
– `readFile` (8)
– `writeFile` (9)
– `rename` (10)
– `copy` (11)
– `unlink` (12)
– `search` (13)
– `touch` (14)
– `sessionStat` (15)
– `requestCommit` (16)
– `QRIntentData` (17)
– `commit` (18)
– `fileContent` (19)
– `directoryContent` (20)
– `enterDir` (21)
– `createDir` (22)
– `sync` (23)
– `commitSuccess` (24)
– `syncSuccess` (25)
– `enterDirLS` (26)
– `commitPending` (27)
– `commitAborted` (28) -
eCommitState
This enumeration describes the state of decentralized processing threads’ commitment operation:
– `none` (0): There is no commit operation taking place.
– `prePending` (1): A commit operation is prepared but not yet active.
– `pending` (2): A commit operation is active and has been confirmed by the full node.
– `aborted` (3): A commit operation has been aborted. -
eOperationStatus
This enumeration is used to describe the status of an operation within a consensus task:
– `success` (0): The operation completed successfully.
– `failure` (1): The operation failed.
– `inProgress` (2): The operation is currently in progress.
– `interrupted` (3): The operation was interrupted. -
eOperationScope
This enumeration is used to describe the scope of an operation within a consensus task:
– `dataTransit` (0): The operation is about data delivery.
– `peer` (1): The operation is local to a peer.
– `VM` (2): The operation is within the scope of the decentralized virtual machine.
– `other` (3): The operation is of another unspecified type.
– `Consensus` (4): The operation is within the scope of consensus. -
eConnectionState
This enumeration is used to describe the current state of a connection with the rest of the network:
– `disconnected` (0): There is no active connection.
– `connecting` (1): A connection is currently being established.
– `connected` (2): A connection is active.
– `aboutToShutDown` (3): The connection is about to be closed. -
eLogEntryCategory
This enumeration is used to categorize log entries:
– `network` (0): The log entry relates to network activity.
– `localSystem` (1): The log entry relates to local system activity.
– `VM` (2): The log entry relates to the decentralized virtual machine.
– `debug` (3): The log entry is for debugging purposes.
– `unknown` (4): The category of the log entry is unknown.
– `dApp` (5): The log entry relates to a decentralized application event. -
eBlockchainMode
This enumeration is used to define the operation mode of the blockchain:
– `LIVE` (0): The live version of the blockchain.
– `TestNet` (1): The test version of the blockchain.
– `LIVESandBox` (2): The sandbox mode of the live version of the blockchain, without access to SolidStorage and refreshed on demand.
– `TestNetSandBox` (3): The sandbox mode of the test version of the blockchain, without access to SolidStorage and refreshed on demand.
– `LocalData` (4): The blockchain data is local.
– `Unknown` (5): The mode of the blockchain is unknown. -
eLogEntryType
This enumeration is used to describe the type of a log entry:
– `notification` (0): The log entry is a notification. (Note: This item should be kept first for iteration purposes)
– `warning` (1): The log entry is a warning.
– `failure` (2): The log entry represents a failure.
– `unknown` (3): The type of the log entry is unknown. (Note: This item should be kept last for iteration purposes) -
eConnQuality
This enumeration is used to describe the quality of a connection, as determined through advanced heuristics:
– `none` (0): The connection quality is non-existent or not available.
– `low` (1): The connection quality is low.
– `medium` (2): The connection quality is medium.
– `high` (3): The connection quality is high.
– `max` (4): The connection quality is at the maximum level.
VMFlags
Let’s break down and document these classes:
-
vmFlags
The `vmFlags` class encapsulates flags that describe the state of a decentralized processing thread (Virtual Machine – VM). These flags are stored in a single byte, and their presence is determined by bitwise operations.
Flags
- `isCmdExecutorAvailable` (1): The VM can execute commands.
- `isUIAttached` (2): The VM has a User Interface attached.
- `isThread` (4): The VM is a thread. If not set, it’s the System Thread.
- `isPrivateThread` (8): The VM is a private thread.
- `isNonCommittable` (16): The VM cannot commit transactions.
- `isDataThread` (32): The VM is a data thread.
- `reserved5` (64): Reserved for future use.
- `reserved6` (128): Reserved for future use.
The class provides getter methods to check the status of these flags.
-
CConsensusTask
This class is used to create, manage, and serialize consensus tasks that can be generated by UI dApps. A consensus task is an operation that requires agreement from multiple nodes in the decentralized network. The `CConsensusTask` has multiple properties, such as `mID`, `mType`, `mDescription`, `mProcessID`, `mThreadID`, `mFlags`, `mVersion`, `mSubDescription`, and `mConversationID`, with getters and setters provided for each.
The `getPackedData()` method is used to serialize the consensus task into a binary format using ASN.1 encoding. This is useful for transmitting the task over a network or storing it.
The `instantiate()` method is used to create a new `CConsensusTask` from binary data. It decodes the data using ASN.1 and checks the validity of the resulting structure. If the data is valid, it populates the properties of the `CConsensusTask` and returns the instance; if not, it returns `null`.
Please note that ASN.1 is a standard and flexible notation that describes data structures for representing, encoding, transmitting, and decoding data. It provides a set of formal rules for describing the structure of objects that are independent of machine-specific encoding techniques and is a fundamental tool used in many cryptographic systems.
CProcess and CThread Documentation
The provided code describes two JavaScript classes, `CProcess` and `CThread`.
CProcess
`CProcess` is a class representing a single process in a decentralized computing system. A process consists of one or more windows and threads. The key functionalities of this class include:
- Keeping track of threads and windows.
- Registering new threads and windows.
- Checking whether a thread is part of the process.
- Unregistering threads.
- Managing the process lifecycle.
Key properties include `mID`, `mWindows`, and `mThreads`.
Methods like `getID`, `getThreadIDs`, `getThreads`, `getThreadByID`, `registerWindow`, `hasThread`, `registerThread`, `end`, `unregisterThread`, and `getWindows` provide various functionalities.
CThread
`CThread` is a class representing a thread in a decentralized computing system. In computing, a thread is the smallest sequence of programmed instructions that can be managed independently by an operating system scheduler.
A thread can have various states (as indicated by flags), and it can be part of one or more processes (`mProcessIDs`).
Key properties include `mFlags`, `mIsAlive`, `mID`, `mLastCommitTime`, `mReadyForCommitSince`, `mProcessIDs`, `mHasDataCommitPending`, and `mNodeURI`.
Methods like `setHasDataCommitPending`, `getHasDataCommitPending`, `pingLastCommit`, `getLastCommitTime`, `pingReadyForCommit`, `getReadyForCommitSince`, `setFlags`, `getFlags`, `getUsedByCount`, `getNodeURI`, `getID`, `addProcess`, `removeProcess`, `getIsUsedBy`, `getProcessIDs`, `setIsAlive`, and `getIsAlive` are used to manage these properties and actions.
These classes and their methods are essential for managing the lifecycle and behavior of processes and threads in a decentralized computing environment.
CProcess Documentation
Class: CProcess
The `CProcess` class represents a computing process in a decentralized system. This class is used for managing threads and windows associated with each process.
Properties
- `mID`: ID of the process.
- `mWindows`: Array containing the windows associated with the process.
- `mThreads`: Array containing the threads associated with the process.
Methods
-
getID()
Parameters: None
Return Type: The ID of the process.
Description: Getter function for the `mID` property.
Use Case: Used to retrieve the unique ID of the process for tracking and referencing purposes. -
getPackageID()
Parameters: None
Return Type: The package ID of the process.
Description: Getter function for the package ID associated with the process. It fetches the package ID from the first window object in the `mWindows` array.
Use Case: Used to fetch the package ID associated with the process for tracking and management purposes. -
setID(id)
Parameters: `id` – The ID to be set for the process.
Return Type: None
Description: Setter function for the `mID` property.
Use Case: Used to update the unique ID of the process for tracking and referencing purposes. -
getThreadIDs()
Parameters: None
Return Type: An array containing the IDs of all threads associated with the process.
Description: Getter function for fetching the IDs of all threads associated with the process.
Use Case: Used to fetch the list of thread IDs for a given process for thread management and tracking purposes. -
getThreads()
Parameters: None
Return Type: An array containing all threads associated with the process.
Description: Getter function for fetching all thread objects associated with the process.
Use Case: Used to fetch all thread objects for a given process for thread management and tracking purposes. -
getThreadByID(threadID)
Parameters: `threadID` – The ID of the thread to be fetched.
Return Type: The thread object with the given ID.
Description: Returns the thread object from `mThreads` that matches the given thread ID.
Use Case: Used to fetch a specific thread from the process using the thread’s ID for management and tracking purposes. -
registerWindow(window)
Parameters: `window` – The window object to be registered.
Return Type: Boolean indicating the success or failure of the operation.
Description: Adds the given window object to the `mWindows` array.
Use Case: Used to register a new window to a process for window management purposes. -
hasThread(threadID)
Parameters: `threadID` – The ID of the thread to be checked.
Return Type: Boolean indicating whether the process has the given thread.
Description: Checks if the given thread ID is associated with the process.
Use Case: Used to verify if a specific thread is part of a given process for thread management and tracking purposes. -
registerThread(threadID)
Parameters: `threadID` – The ID of the thread to be registered.
Return Type: Boolean indicating the
success or failure of the operation.
Description: Adds a new thread object with the given ID to the `mThreads` array.
Use Case: Used to register a new thread to a process for thread management purposes.
-
end()
Parameters: None
Return Type: None
Description: Ends the process by freeing all its associated threads.
Use Case: Used to end a process and free all its threads for process management purposes. -
unregisterThread(threadID)
Parameters: `threadID` – The ID of the thread to be unregistered.
Return Type: Boolean indicating the success or failure of the operation.
Description: Removes the thread with the given ID from the `mThreads` array.
Use Case: Used to unregister a thread from a process for thread management purposes. -
getWindows()
Parameters: None
Return Type: An array containing all windows associated with the process.
Description: Getter function for fetching all window objects associated with the process.
Use Case: Used to fetch all window objects for a given process for window management and tracking purposes.
CThread Documentation
Class: CThread
The `CThread` class represents a computing thread in a decentralized system. This class is used for managing different aspects of a thread, like its ID, the processes using it, its flags, commit times, and more.
Properties
- `mID`: ID of the thread.
- `mFlags`: Flags associated with the thread.
- `mIsAlive`: Boolean representing the thread’s alive status.
- `mProcessIDs`: Array containing the IDs of processes using this thread.
- `mNodeURI`: The URI of the node.
- `mHasDataCommitPending`: Boolean flag indicating if a data commit is pending.
- `mLastCommitTime`: The time of the last commit.
- `mReadyForCommitSince`: The time since the thread is ready for commit.
Methods
-
-
setHasDataCommitPending(hasIt)
Parameters: `hasIt` – Boolean value to be set.
Return Type: None.
Description: Setter function for the `mHasDataCommitPending` property.
Use Case: Used to set the flag indicating if a data commit is pending for the thread. -
getHasDataCommitPending()
Parameters: None.
Return Type: Boolean value of `mHasDataCommitPending`.
Description: Getter function for the `mHasDataCommitPending` property.
Use Case: Used to check if a data commit is pending for the thread. -
pingLastCommit()
Parameters: None.
Return Type: None.
Description: Updates the `mLastCommitTime` with the current time.
Use Case: Used to update the time of the last commit for the thread. -
getLastCommitTime()
Parameters: None.
Return Type: The time of the last commit.
Description: Getter function for the `mLastCommitTime` property.
Use Case: Used to fetch the time of the last commit for the thread. -
pingReadyForCommit()
Parameters: None.
Return Type: None.
Description: Updates the `mReadyForCommitSince` with the current time.
Use Case: Used to update the time since the thread is ready for commit. -
getReadyForCommitSince()
Parameters: None.
Return Type: The time since the thread is ready for commit.
Description: Getter function for the `mReadyForCommitSince` property.
Use Case: Used to fetch the time since the thread is ready for commit. -
setFlags(flags)
Parameters: `flags` – The flags to be set for the thread.
Return Type: None.
Description: Setter function for the `mFlags` property.
Use Case: Used to set the flags associated with the thread. -
getFlags()
Parameters: None.
Return Type: The flags of the thread.
Description: Getter function for the `mFlags` property.
Use Case: Used to fetch the flags associated with the thread. -
getUsedByCount()
Parameters: None.
Return Type: The count of processes using the thread.
Description: Getter
-
function for the length of the `mProcessIDs` array.
Use Case: Used to fetch the count of processes using the thread.
-
getNodeURI()
Parameters: None.
Return Type: The URI of the node.
Description: Getter function for the `mNodeURI` property.
Use Case: Used to fetch the URI of the node associated with the thread. -
getID()
Parameters: None.
Return Type: The ID of the thread.
Description: Getter function for the `mID` property.
Use Case: Used to fetch the ID of the thread. -
addProcess(id)
Parameters: `id` – The ID of the process to be added.
Return Type: None.
Description: Adds a process ID to the `mProcessIDs` array.
Use Case: Used to register a process to a thread for thread management purposes. -
removeProcess(id)
Parameters: `id` – The ID of the process to be removed.
Return Type: Boolean – True if the process is successfully removed; False otherwise.
Description: Removes a process ID from the `mProcessIDs` array.
Use Case: Used when a process no longer needs to use this thread. It will remove the process ID from the list of processes that are currently using this thread. -
getIsUsedBy(id)
Parameters: `id` – The ID of the process.
Return Type: Boolean – True if the thread is used by the process; False otherwise.
Description: Checks if the thread is being used by a process.
Use Case: Used to check if a specific process is using the thread. It will be helpful in thread management to know which processes are currently using a thread. -
getProcessIDs()
Parameters: None.
Return Type: Array of process IDs (`mProcessIDs`).
Description: Getter function for the `mProcessIDs` property.
Use Case: Used to fetch the IDs of processes that are currently using this thread. -
setIsAlive(value)
Parameters: `value` – Boolean value to set the thread’s alive status.
Return Type: None.
Description: Setter function for the `mIsAlive` property.
Use Case: Used to set the alive status of the thread. It might be used when starting or stopping a thread. -
getIsAlive()
Parameters: None.
Return Type: Boolean – The alive status of the thread.
Description: Getter function for the `mIsAlive` property.
Use Case: Used to fetch the current alive status of the thread. It could be used to check if a thread is still active or has been terminated.
The CThread class is used to manage and manipulate threads of execution within a process. It encapsulates the state of a thread and provides methods to get and set various thread attributes such as its ID, flags, associated process IDs, and alive status. In addition, it also provides utility methods to handle processes that are using the thread.
The CProcess class represents a process that can have multiple windows and threads associated with it. It provides methods to manage these windows and threads, including registering and unregistering windows, registering threads, and retrieving the IDs of associated threads.
Together, the CProcess and CThread classes provide a model for managing processes and threads in the context of a multi-threaded, multi-window application.
CJSThread Documentation
Class: CJSThread
The `CJSThread` class represents a client-side JavaScript-based thread. This class allows execution of an arbitrary function at a given interval, even if the web-browser is not in focus.
Properties
- `mID`: The unique ID of the JavaScript-based thread.
- `mActive`: A boolean indicating if the thread is active or not.
- `mProcessID`: The ID of the process associated with this thread.
- `mIsKernelMode`: A boolean indicating if the thread is in Kernel mode or not.
- `mIntervalMS`: The interval in milliseconds at which the function is executed.
- `mJSIntervalID`: The ID returned by the `setTimeout` function.
- `mFuncPtr`: A pointer to the function to be executed.
- `mExecutionGuardian`: A mutex used for protecting the function execution.
- `mStartTimestamp`: The timestamp marking the start of the thread.
- `mEndTimestamp`: The timestamp marking the end of the thread.
- `mInterationsCount`: The number of times the function has been executed.
Methods
-
processID()
Parameters: None
Return Type: The ID of the process associated with this thread.
Description: Getter function for the `mProcessID` property.
Use Case: Used to fetch the process ID associated with the thread for management and tracking purposes. -
start()
Parameters: None
Return Type: None
Description: Starts the execution of the thread function at the given interval.
Use Case: Used to start the execution of a thread for performing a task at regular intervals. -
stop()
Parameters: None
Return Type: None
Description: Stops the execution of the thread function.
Use Case: Used to stop the execution of a thread when the task is completed or when the process is ending. -
isKernelMode()
Parameters: None
Return Type: Boolean indicating whether the thread is in Kernel mode or not.
Description: Getter function for the `mIsKernelMode` property.
Use Case: Used to check if a thread is running in Kernel mode. -
iterationsCount()
Parameters: None
Return Type: The number of times the thread function has been executed.
Description: Getter function for the `mInterationsCount` property.
Use Case: Used to fetch the number of times a thread function has been executed for debugging and performance analysis purposes. -
isAlive()
Parameters: None
Return Type: Boolean indicating whether the thread is active or not.
Description: Getter function for the `mActive` property.
Use Case: Used to check if a thread is active or not for thread management purposes. -
id()
Parameters: None
Return Type: The unique ID of the thread.
Description: Getter function for the `mID` property.
Use Case: Used to retrieve the unique ID of the thread for tracking and referencing purposes. -
funcWrapper()
Parameters: None
Return Type: None
Description: This function is a wrapper for the function to be executed.
Class CVMMetaSection
Class: CVMMetaSection
The `CVMMetaSection` class represents a section within the VM Meta Data protocol. It acts as a container for multiple `CVMMetaEntry` objects. The `CVMMetaSection` type is specified through the previously defined `eVMMetaSectionType` enum. A single meta-data protocol package may contain multiple sections.
Properties
The `CVMMetaSection` class doesn’t explicitly define its own properties. However, based on the usage context, it could contain multiple `CVMMetaEntry` objects.
Methods
The `CVMMetaSection` class doesn’t explicitly define its own methods. Methods for adding, removing, and manipulating `CVMMetaEntry` objects within a `CVMMetaSection` would be defined in other classes or modules that use `CVMMetaSection`.
—
Class: CVMMetaEntry
The `CVMMetaEntry` class represents a unit of data within a `CVMMetaSection`. The type of a `CVMMetaEntry` is specified through the previously defined `eVMMetaEntryType` enum. This class allows for the packing and unpacking of data which can pass full-node, web-browser, and mobile app boundaries.
Properties
The `CVMMetaEntry` class doesn’t explicitly define its own properties. However, based on the usage context, it is expected to encapsulate data of a specified type and related metadata (like its type).
Methods
The `CVMMetaEntry` class doesn’t explicitly define its own methods. Methods for setting and retrieving the data and metadata of a `CVMMetaEntry` would be defined in other classes or modules that use `CVMMetaEntry`.
—
The explicit properties and methods for both `CVMMetaSection` and `CVMMetaEntry` are not provided in the given information. However, their functionality is understood based on their description. It’s suggested to provide more specific code or information for a more detailed analysis and documentation.
Both `CVMMetaSection` and `CVMMetaEntry` are essential parts of the VM Meta Data protocol. `CVMMetaSection` serves as a container for `CVMMetaEntry` objects, effectively grouping related data together. `CVMMetaEntry` objects, in turn, encapsulate individual units of data along with their metadata. This structured way of arranging data facilitates efficient data serialization, transmission, and deserialization across various system boundaries like full-nodes, web-browsers, and mobile apps.
CVMMetaGenerator Class
The `CVMMetaGenerator` class is a part of the VM Meta Data sub-system. It is responsible for generating VM Meta Data to be used for various functionalities in the VM.
Here is a detailed documentation of its methods and accessors:
Methods
-
-
-
constructor()
Initializes a new instance of the `CVMMetaGenerator` class. It sets the `mSections` array to an empty array and `mVersion` to 1. -
addRAWGridScriptCmd(cmd, mode, reqID = 0, windowID = 0, processID = 0, vmID = new ArrayBuffer())
Adds a RAW Grid Script command to a section in `mSections`.
Parameters:
– `cmd`: A string representing the command to be added. If the `cmd` is null, undefined, or an empty string, an empty string is added instead.
– `mode`: Represents the mode of the command.
– `reqID`: Optional, identifies the request.
– `windowID`: Optional, identifies the window.
– `processID`: Optional, identifies the process.
– `vmID`: Optional, an `ArrayBuffer` representing the VM ID.Returns: Request ID of the entry added.
-
-
addTerminalData(data1, data2 = new ArrayBuffer(), dType = eTerminalDataType.input, reqID = 0, processID = 0, vmID = new ArrayBuffer())
Adds terminal data to a section in `mSections`.
Parameters:
– `data1`: First data value.
– `data2`: Optional, second data value. Default is an empty `ArrayBuffer`.
– `dType`: Optional, type of the terminal data. Default is ‘input’.
– `reqID`: Optional, identifies the request.
– `processID`: Optional, identifies the process.
– `vmID`: Optional, an `ArrayBuffer` representing the VM ID.Returns: Request ID of the entry added.
-
addStateLessChannelElement(name, eType, serializedData, reqID = 0, processID = 0, vmID = new ArrayBuffer())
Adds a stateless channel element to a section in `mSections`.
Parameters:
– `name`: Name of the stateless channel element.
– `eType`: The type of the element.
– `serializedData`: Serialized data of the element.
– `reqID`: Optional, identifies the request.
– `processID`: Optional, identifies the process.
– `vmID`: Optional, an `ArrayBuffer` representing the VM ID.Returns: Request ID of the entry added.
-
addBankAuthRequest(bankID, value, tpID, reqID = 0, processID = 0, vmID = new ArrayBuffer())
Adds a bank authorization request to a section in `mSections`.
Parameters:
– `bankID`: The bank ID for the request.
– `value`: The value for the request.
– `tpID`: Token Pool ID for the request.
– `reqID`: Optional, identifies the request.
– `processID`: Optional, identifies the process.
– `vmID`: Optional, an `ArrayBuffer` representing the VM ID.Returns: Request ID of the entry added.
-
clear()
Clears the `mSections` array. -
addGenTokenPoolRequest(tp, reqID = 0, processID = 0, vmID = new ArrayBuffer())
Requests Token Pool generation.
Parameters:
– `tp`: Instance of `CTokenPool`.
– `reqID`: Optional, identifies the request.
– `processID`: Optional, identifies the process.
– `vmID`: Optional, an `ArrayBuffer` representing the VM ID.Returns: Request ID of the entry added.
-
addGetTokenPoolRequest(tpID, reqID = 0, processID = 0, vmID = new ArrayBuffer())
Requests Token Pool.
Parameters:
– `tpID`: Token Pool ID.
– `reqID`: Optional, identifies the request.
– `processID`: Optional, identifies the process.
– `vmID`: Optional, an `ArrayBuffer` representing the VM ID.Returns: Request ID of the entry added.
-
addChannelElementRequest(name, reqID = 0, processID = 0, vmID = new ArrayBuffer())
Requests a channel element.
Parameters:
– `name`: Name of the channel element.
– `reqID`: Optional, identifies the request.
– `processID`: Optional, identifies the process.
– `vmID`: Optional, an `ArrayBuffer` representing the VM ID.Returns: Request ID of the entry added.
-
generateMeta(binSize, nSections)
Generates meta data.
Parameters:
– `binSize`: The size of the binary.
– `nSections`: The number of sections.Returns: An `ArrayBuffer` containing the meta data.
-
Accessors
-
sections
Gets the sections of the `CVMMetaGenerator` instance.
-
version
Gets the version of the `CVMMetaGenerator` instance.
