This document is a rather technical. It explains how to use AvesTerra and not what AvesTerra is. See the other more friendly page of the wiki if you are searching for more general explainations of AvesTerra.
TODO: Separate the higher-level less technical details into different pages, so people can easily look up the easy stuff, and only have to dive that deep when they need to know some specific stuff
This document is a language agnostic technical documentation of all the ATAPI (AvesTerra API) operations.
The goal of this document is to serve as the one central reference to document the behavior of the operations and the effect of their various parameters as opposed to continually copy-pasting less than up-to-date bits of documentation in the implementations of this API in various languages.
This documentation is made to be a more up-to-date version of the document
https://avesterra.georgetown.edu/tech/ - Application Programming Interface (API)
which is becomming more and more innacurate as time goes.
This document was written as an aggregation of data from reading the document linked above, reading the source code of the various AvesTerra/Avial client implementations provided from GeorgeTown, the old documentation from the LEDR C client era, as well as empirically testing of the effect of the various arguments.
Everybody is encouraged to make changes if they see some mistake or inaccuracies, as this is the only way to grow this documentation and make it robust.
When the documentation becomes good enough, we may want to give it to GeorgeTown and ask them to take ownership of it, keep it up-to-date and distribute it with every new version of AvesTerra
Note: This document only concerns the AvesTerra layer, and does not include any Avial construct or any other layer above AvesTerra.
We should also have the same kind of central documentation about Avial, but it will require a lot of upfront work until it buys that work back by improving the quality of life of any developper, especially those who are new to AvesTerra
¶ Entity operations
6 operations:
- CREATE
- DELETE
- INVOKE
- INQUIRE
- REFERENCE
- DEREFERENCE
¶ CREATE
The CREATE operation is used to create a new entity in the AvesTerra knowledge space. In general, this operation allocates and records a UUID for the new entity so that it may be referenced and distinguished from all other entities in the space.
Once created, the entity may be accessed via the API from any location across an AvesTerra deployed enterprise with network connectivity (e.g. the Internet)\
Authorization: Only the server's (<0|0|0>) authority or a server's authorization may perform this operation. An entity created with an authorization that gets removed from the server's authorizations will not be deleted and will stay operational
The Entity's authority will be the given Authorization, though it can be changed later to be any arbitrary authority (including null Authorization, which would grand anyone the ability to modify the entity)
Click to see arguments
¶ Authorization |
The authorization to use when creating the entity. This will be the authority of the entity. One may pass in the null Authorization to indicate that no authorization is required to modify/delete the entity, however this is obviously not recommended for anything but testing. |
¶ Outlet |
If Method is also provided, the Outlet will get connected to the entity with Method and Precedence (Precedence may be null). If Attribute is also provided, the Outlet will get attached to the entity with Attribute and Precedence (Precedence may be null). If Event is also provided, the Outlet will get subscribed to the entity with Event. The Outlet must have already been activated, see ACTIVATE |
¶ Entity |
Specifies the AvesTerra server to which the entity should be created. |
¶ Name |
The name of the entity to be created. Name need not be unique |
¶ Key |
The preferred registry key to use when referring to this entity |
¶ Context |
The ontological context of the entity to be created. |
¶ Category |
The ontological category of the entity to be created. |
¶ Class |
The ontological class of the entity to be created. |
¶ Method |
Only used if Outlet is provided. |
¶ Attribute |
Only used if Outlet is provided. |
¶ Event |
Only used if Outlet is provided. |
¶ Precedence |
Only used if Outlet is provided. |
¶ Timeout |
Maximum wait time in seconds for the call. The timeout specifies the maximum amount of time the call is allowed to take. If the call takes longer than the timeout, the call is aborted and a Timeout error is returned. If no timeout argument is provided, a null value of |
¶ DELETE
The DELETE operation is used to permanently delete an entity and ensures that its EUID is never reused.
Authorization:
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a modification, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action
Click to see arguments
¶ Entity |
The entity to be deleted |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **modification**, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action |
¶ INVOKE
The INVOKE operation is perhaps among the most heavily used of all AvesTerra API operations. It's purpose is to provide access to an entity's methods. Entities may have any number of methods (zero or more). An entity's methods are determined by the outlets to which the entity has been connected (see CONNECT). The semantic of the invocation depends upon the the ontology of said method as well as the outlet/adapter that will handle the call
When an AvesTerra server receives a method invocation request via an API call, the server first examines the entity's identifier. If the entity is local, the server next examines the entity's connections, forwarding the invoke request to the associated outlet with the same assigned precedence than the optional Precedence parameter. If no precedence value is specified, defaults to 0. If the specified entity is not local, then the request is forwarded to the remote AvesTerra server where the entity is managed (i.e. where it was created). The remote server processes the request, returning a response back to the originating local server for request fulfillment and completion of the API INVOKE call. Attempts to invoke methods on entities that are not connected via an outlet result in an Entity error being returned.
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a simple usage of the entity, therefore one can use either the entity's authority or one of the entity's authorizations.
// TODO: What happens if we Invoke before the adapter adapts? Does the remote rendez-vous still occur?
Click to see arguments
¶ Entity |
The entity whose method is to be invoked |
¶ Method |
The method to be invoked. Valid method are defined by the ontology. If no method argument is provided, a null method is assumed |
¶ Auxiliary |
Can be used as a supplementary entity id. A common pattern is to use the auxiliary when an invoked method may require a long amount of time to execute. Rather than waiting for the results, the invoker can provide an auxiliary entity as a destination of the results, and then proceed asynchronously with other work, and pick up the results from the entity at some later date |
¶ Ancillary |
Can be used if the adapter uses this argument |
¶ Attribute |
Can be used if the adapter uses this argument |
¶ Instance |
Can be used if the adapter uses this argument |
¶ Offset |
Can be used if the adapter uses this argument |
¶ Name |
Can be used if the adapter uses this argument |
¶ Key |
Can be used if the adapter uses this argument |
¶ Bytes |
Can be used if the adapter uses this argument If you supply Bytes, you probably also want to supply Tag to indicate what is the type of that data |
¶ Parameter |
Can be used if the adapter uses this argument |
¶ Resultant |
Can be used if the adapter uses this argument |
¶ Index |
Can be used if the adapter uses this argument |
¶ Count |
Can be used if the adapter uses this argument |
¶ Aspect |
Can be used if the adapter uses this argument |
¶ Context |
Can be used if the adapter uses this argument |
¶ Category |
Can be used if the adapter uses this argument |
¶ Class |
Can be used if the adapter uses this argument |
¶ Event |
Can be used if the adapter uses this argument |
¶ Mode |
Can be used if the adapter uses this argument |
¶ State |
Can be used if the adapter uses this argument |
¶ Condition |
Can be used if the adapter uses this argument |
¶ Precedence |
`Precedence` determines which outlet is to be passed the invocation request. The invoke call will only get forwarded to the adapter adapting on the outlet connected with this precedence. Then the adapter may chose to forward the call to the next lower precedence outlet. See avesterra Error documentation for more detail |
¶ Tag |
Can be used if the adapter uses this argument Usually used to indicate the type of the data given through the Bytes argument |
¶ Time |
Can be used if the adapter uses this argument |
¶ Timeout |
Maximum wait time in seconds for the invocation. The timeout specifies the maximum amount of time the call is allowed to take. If the call takes longer than the timeout, the call is aborted and a Timeout error is returned. If no timeout argument is provided, a null value of |
¶ Authority |
Can be used if the adapter uses this argument |
¶ Authorization |
The authorization to issue the call with Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **simple usage** of the entity, therefore one can use either the entity's authority or one of the entity's authorizations. |
¶ INQUIRE
The INQUIRE operation is very similar to the INVOKE operation, but formulated primarily for entity attribute retrieval. Entities may have any number of attributes (zero or more). An entity's attributes are determined by the outlets to which the entity has been attached (see ATTACH). The semantic of inquiry depends upon the the ontology of said attribute as well as the outlet/adapter that will handle the call
When an AvesTerra server receives an attribute inquisition request via an API call, the server first examines the entity's identifier. If the entity is local, the server next examines the entity's attachment, forwarding the inquiry request to the associated outlet with the same assigned precedence than the optional Precedence parameter. If no precedence value is specified, defaults to 0. If the specified entity is not local, then the request is forwarded to the remote AvesTerra server where the entity is managed (e.g. where it was created). The remote server processes the request, returning a response back to the originating local server for request fulfillment and completion of the API INQUIRE call. The INQUIRE operation returns the value of the specified entity's attribute as the result. Attempts to inquire attributes on entities that are not attached via an outlet result in an Entity error being returned.
Authorization:
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a simple usage of the entity, therefore one can use either the entity's authority or one of the entity's authorizations.
Click to see arguments
¶ Entity |
The entity whose attribute is to be inquired |
¶ Attribute |
The attribute to be inquired. Valid attribute are defined by the ontology. If no attribute argument is provided, a null attribute (`0`) is assumed |
¶ Auxiliary |
Can be used as a supplementary entity id. A common pattern is to use the auxiliary when an inquired attribute may require a long amount of time to execute. Rather than waiting for the results, the inquier can provide an auxiliary entity as a destination of the results, and then proceed asynchronously with other work, and pick up the results from the entity at some later date |
¶ Ancillary |
Can be used if the adapter uses this argument |
¶ Instance |
Can be used if the adapter uses this argument |
¶ Offset |
Can be used if the adapter uses this argument |
¶ Name |
Can be used if the adapter uses this argument |
¶ Key |
Can be used if the adapter uses this argument |
¶ Bytes |
Can be used if the adapter uses this argument If you supply Bytes, you probably also want to supply Tag to indicate what is the type of that data |
¶ Parameter |
Can be used if the adapter uses this argument |
¶ Resultant |
Can be used if the adapter uses this argument |
¶ Index |
Can be used if the adapter uses this argument |
¶ Count |
Can be used if the adapter uses this argument |
¶ Aspect |
Can be used if the adapter uses this argument |
¶ Context |
Can be used if the adapter uses this argument |
¶ Category |
Can be used if the adapter uses this argument |
¶ Class |
Can be used if the adapter uses this argument |
¶ Event |
Can be used if the adapter uses this argument |
¶ Mode |
Can be used if the adapter uses this argument |
¶ State |
Can be used if the adapter uses this argument |
¶ Condition |
Can be used if the adapter uses this argument |
¶ Precedence |
`Precedence` determines which outlet is to be passed the inquiry request. The invoke call will only get forwarded to the adapter adapting on the outlet connected with this precedence. Then the adapter may chose to forward the call to the next lower precedence outlet. See avesterra Error documentation for more detail |
¶ Tag |
Can be used if the adapter uses this argument Usually used to indicate the type of the data given through the Bytes argument |
¶ Time |
Can be used if the adapter uses this argument |
¶ Timeout |
Maximum wait time in seconds for the inquiry. The timeout specifies the maximum amount of time the call is allowed to take. If the call takes longer than the timeout, the call is aborted and a Timeout error is returned. If no timeout argument is provided, a null value of |
¶ Authority |
Can be used if the adapter uses this argument |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **simple usage** of the entity, therefore one can use either the entity's authority or one of the entity's authorizations. |
¶ REFERENCE
The REFERENCE/DEREFERENCE operations are provided in support of automated "garbage collection". Associated with each entity is a counter that records the number of times the entity is been referenced.
Associated with every entity is also a timestamp that records the Universal Time when the entity was created. When an entity reference count remains at zero beyond a fixed period of time, a garbage collection system, if included in an AvesTerra implementation, may choose to automatically delete the entity, if it is non-persistent. Details of garbage collection including delay times and frequency of inspection are implementation defined.
When the REFERENCE operation is called, the request is forwarded to the server that manages the entity, which then increments this counter by one or by Count if provided.
The opposite operation is DEREFERENCE
Authorization:
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a modification, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action
Click to see arguments
¶ Entity |
The entity to be referenced |
¶ Count |
The number by which the reference count will be incremented. If not specified if `0`, the reference count will be incremented by one. |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **modification**, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action |
¶ DEREFERENCE
The opposite operation is REFERENCE
When the DEREFERENCE operation is called, this counter is decremented by one or by Count if provided. The counter is never decremented below zero.
When the reference count of an entity reaches 0, it may be garbage collected by the AvesTerra server at any time, but usually the garbage collector runs on server reboot
Authorization:
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a modification, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action
Click to see arguments
¶ Entity |
The entity to be dereferenced |
¶ Count |
The number by which the reference count will be decrement.a If not specified if `0`, the reference count will be decremented by one. The reference cound will never be negative, and will stop at 0 if one try to decrement it further //TODO: If Count is zero, does it set the reference count to 0 ? |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **modification**, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action |
¶ Connection operations
3 operations:
- CONNECT
- DISCONNECT
- CONNECTION
¶ CONNECT
The CONNECT operation is used to connect an entity to the outlet that will respond to method invocations on the entity (see the INVOKE operation). The outlet itself is also an entity, and must be handled by the same server that manages the entity, otherwise an Entity error is returned.
TODO: is that true?
The connection is recorded the entity connection lists, in its metadata.
The connection is a one-way link, the outlet does not know how many or what entities hold a connection to it. The connection is optionnaly assigned a method and a precedence value. If an entity has multiple outlet connected, the method and precedence will be used to determine which connected outlet is invoked when the entity is invoked.
If a connection already exists for this method and precedence, it will be overwritten.
see INVOKE for more details.
Authorization:
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a modification, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action
Click to see arguments
¶ Entity |
The entity we want add a connection to |
¶ Outlet |
The outlet that will be used as a bridge between the entity and the adapter that will handle the INVOKE request The Outlet must have been activated before the connection can be made, see ACTIVATE |
¶ Method |
Filter the connection on a specific method. The default is null method (`0`), which means invoke of any method will be forwarded to the outlet. |
¶ Precedence |
Filter the connection on a specific precedence. If no precedence is specified, the connection will assume the smallest available precedence at the time of creation of the connection TODO: Check if this last statement is correct If `Precedence` is specified but a method is already connected to the entity at that precedence level, an Entity error is returned. The adapter may chose to forward the call to the next lower precedence outlet. See avesterra Error documentation for more detail TODO: Elaborate on how that can be used |
¶ Timeout |
TODO: Is THAT correct? Or does A timeout to specify after how many seconds a connection should disconnect like docs.ledr.io says ???? Or maybe the timeout for remote rendez-vous? Or is it the expiry of the connection? (see CONNECTION) Maximum wait time in seconds for the call. If no timeout argument is provided, a null value of |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **modification**, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action |
¶ DISCONNECT
The DISCONNECT operation is used to disconnect a method from an entity, effectively deleting that connection from the connections Entity
If such a connection does not exist, the operation has no effect
TODO: is this correct? no error and is a noop??
TODO: Document better how the various arguments behave when combined together
Authorization:
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a modification, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action
Click to see arguments
¶ Entity |
The entity we want to disconnect |
¶ Outlet |
The outlet we want to disconnect from |
¶ Method |
The method of the connection to delete. The default is null method (`0`) |
¶ Precedence |
The precedence of the connection to delete The default is null precedence (`0`) |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **modification**, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action |
¶ CONNECTION
The CONNECTION operation is used to get the outlet, method and precedence of a connection of an entity at a given index.
Entity connections are indexed from 1 to the total number of connections the entity posseses, available through the CONNECTIONS operation.
Authorization:
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a simple usage of the entity, therefore one can use either the entity's authority or one of the entity's authorizations.
Click to see arguments
¶ Entity |
The entity we want to get the connection of |
¶ Index |
The 1-based index of the connection to get from its connection list. If not specified or `0`, the last connection is returned (the one created the most recently). One can get the number of connections by calling CONNECTIONS |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **simple usage** of the entity, therefore one can use either the entity's authority or one of the entity's authorizations. TODO: can we read the entity if its authority/authorization is `ViewAuthorization`? |
¶ Attachment operations
3 operations:
- ATTACH
- DETACH
- ATTACHMENT
¶ ATTACH
The ATTACH operation is used to connect an entity to the outlet that will respond to attribute inquiry on the entity (see the INQUIRE operation). The outlet itself is also an entity, and must be handled by the same server that manages the entity, otherwise an Entity error is returned.
TODO: is that true?
The connection is recorded the entity connection lists, in its metadata.
The connection is a one-way link, the outlet does not know how many or what entities hold a connection to it.
TODO: is that true?
The attachment is optionnaly assigned an attribute and a precedence value. If an entity has multiple outlet attached, the attribute and precedence will be used to determine which connected outlet is inquired when the entity is inquired.
If an attachment already exists for this attribute and precedence, it will be overwritten.
see INQUIRE for more details.
Authorization:
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a modification, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action
Click to see arguments
¶ Entity |
The entity we want add a connection to |
¶ Outlet |
The outlet that will be used as a bridge between the entity and the adapter that will handle the INQUIRE request The Outlet must have been activated before the connection can be made, see ACTIVATE |
¶ Attribute |
Filter the attachment on a specific attribute. The default is null attribute (`0`), which means inquire for any attribute will be forwarded to the outlet. |
¶ Precedence |
Filter the attachment on a specific precedence. If no precedence is specified, the attachment will assume the smallest available precedence at the time of creation of the attachment TODO: Check if this last statement is correct If `Precedence` is specified but an attribute is already attached to the entity at that precedence level, an Entity error is returned. The adapter may chose to forward the call to the next lower precedence outlet. See avesterra Error documentation for more detail TODO/J: Elaborate on how that can be used |
¶ Timeout |
TODO: Is THAT correct? Or does A timeout to specify after how many seconds a connection should detatch like docs.ledr.io says ???? Or maybe the timeout for remote rendez-vous? Or is it the expiry of the attachment ? (see ATTACHMENT) Maximum wait time in seconds for the call. The timeout specifies the maximum amount of time the call is allowed to take. If the call takes longer than the timeout, the call is aborted and a Timeout error is returned. If no timeout argument is provided, a null value of |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **modification**, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action |
¶ DETACH
The DETACH operation is used to disconnect an attribute from an entity, effectively deleting that attachment from the attachments of Entity.
If such a connection does not exist, the operation has no effect
TODO: is this correct? no error?
If such an attachment does not exist, an Entity error is returned.
Authorization:
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a modification, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action
Click to see arguments
¶ Entity |
The entity we want to detach |
¶ Outlet |
The outlet we want to detach from |
¶ Attribute |
The attribute of the attachment to delete. The default is null attribute (`0`) |
¶ Precedence |
The precedence of the attachment to delete The default is null precedence (`0`) |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **modification**, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action |
¶ ATTACHMENT
The ATTACHMENT operation is used to get the outlet, method and precedence of an attachment of an entity at a given index.
Entity attachments are indexed from 1 to the total number of attachments the entity posseses, available through the ATTACHMENTS operation.
Authorization:
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a simple usage of the entity, therefore one can use either the entity's authority or one of the entity's authorizations.
Click to see arguments
¶ Entity |
The entity to get an attachment of |
¶ Index |
The 1-based index of the connection to get from its attachment list. If not specified or `0`, the last attachment is returned (the one created the most recently). One can get the number of attachments by calling ATTACHMENTS |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **simple usage** of the entity, therefore one can use either the entity's authority or one of the entity's authorizations. TODO: can we read the entity if its authority/authorization is `ViewAuthorization`? |
¶ Outlet operations
4 operations:
- ACTIVATE
- DESACTIVATE
- ADAPT
- RESET
¶ ACTIVATE
The ACTIVATE operation is used to create an entity interface point (outlet). Internally, this involves the allocation of the resources necessary to support the rendezvous/queuing mechanisms the particular AvesTerra implementation requires. Attempts to activate an entity that is already activated has no effect.
The opposite of this operations is DEACTIVATE.
Authorization:
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a modification, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action
Click to see arguments
¶ Outlet |
The outlet to activate |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **modification**, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action |
¶ DEACTIVATE
The DEACTIVATE operation is used to release the interface point resources allocated to an entity on which we called ACTIVATE. If the outlet/entity hasn't been activated (eg it is a simple entity, not an outlet), the DEACTIVATE operation has no effect.
Warning: This operation will not DISCONNECT connections/attachment any entity may have to this outlet, therefore any subsequent INVOKE or INQUIRE given to this previously outlet now entity will fail with an Outlet error.
The opposite of this operations is ACTIVATE.
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a modification, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action
Click to see arguments
¶ Outlet |
The outlet to desactivate |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **modification**, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action |
¶ ADAPT
The ADAPT operation is used by software adapters to receive and process entity invocation requests. Adapters communicate with outlets via this operation.
If the Entity has previously been connected (see CONNECT) to the outlet, the flow looks like that:
NOTE: This diagram says "INVOKE" but it may as well say "INQUIRE", the rendezvous mechanism works the same way.
Execution of this operation awaits a rendezvous with a client software processes within the AvesTerra enterprise. The rendezvous occurs when the client requests invocation of an entity's method or inquisition of an entity's attribute (i.e. executes either the INVOKE or INQUIRE operation). These requests are forwarded to the AvesTerra server where the entity that is providing the outlet interfacing point is managed. When the request arrives at the outlet, the invocation/inquistion parameters are passed in rendezvous fashion to the adapter. The specific order of arrival at the outlet of the client request and the ADAPT operation call is not important. The outlet's role is to coordinate the two, transferring the request parameters to the adapter when the two meet. This transfer is accomplished via the adapter parameter specified during the ADAPT call. This parameter specifies an adapter callback function (i.e. its address) to be called upon rendezvous at the outlet with an incoming INVOKE or INQUIRE request.
The adapter will directly receive exactly the same INVOKE/INQUIRE request the client sent to the AvesTerra server, with the Outlet field completed by the server to indicate the Outlet the rendezvous has taken place in.. When the adapter has completed the invocation request, its return result is passed back across the outlet rendezvous point, and then reverse forwarded back to the requesting client process where it is returned as the response to the original INVOKE or INQUIRE operation.
This ADAPT mechanism can be thought of declaring that the adapter is now the server that will handle that particular job (answering INVOKE/INQUIRE), and the AvesTerra server will simply proxy requests from the client to the adapter, and the response back to the client. One ADAPT call will only be match to serve one INVOKE/INQUIRE request, however in practice, adapters usually call ADAPT again as soon as they're done serving the INVOKE/INQUIRE request, and maybe even have multiple threads all adapting concurrently and all adapting again if they're done serving a request.
Two interesting errors the adapter can return are Bypass error and Forward error
See the AvesTerra error (wiki page TODO) for more information.
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a modification, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action
Click to see arguments
¶ Outlet |
The outlet to adapt onto |
¶ Timeout |
TODO |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **modification**, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action |
¶ RESET
The RESET operation is used to re-synchronize an outlet after a failure that could have left the outlet in an undefined states.
Outlets are designed to persist independent of any adapter or the AvesTerra server managing it shutdown or restart, however in the event of a component failure, the state of the outlet may be left undefined. For example, an outlet may have only partially completed the initial portion of an invocation or inquisition rendezvous, awaiting communication with an adapter that may have just failed.
When reseting an outlet, any pending request may be lost. However, the process issuing the original INVOKE or INQUIRE request will receive an Entity error error to signal the incompletion of the operation to facilitate recovery.
TODO: Does that reset the state of the lock?
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a modification, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action
Click to see arguments
¶ Outlet |
The outlet to reset |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **modification**, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action |
¶ Event operations
5 operations:
- PUBLISH
- SUBSCRIBE
- UNSUBSCRIBE
- WAIT
- SUBSCRIPTION
¶ PUBLISH
The PUBLISH operation is used to publish an event on an entity. Upon completion, all processes with active subscriptions to this event on the specified entity will receive a notification via a call to their specified subscriber procedure
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a simple usage of the entity, therefore one can use either the entity's authority or one of the entity's authorizations.
Click to see arguments
¶ Entity |
The entity on which to publish the event |
¶ Event |
The Event to publish. Valid event are defined by the ontology. If no event argument is provided, a null event (`0`) is assumed |
¶ Auxiliary |
Can be used as a supplementary entity id. A common pattern is to use the auxiliary when an invoked method may require a long amount of time to execute. Rather than waiting for the results, the invoker can provide an auxiliary entity as a destination of the results, and then proceed asynchronously with other work, and pick up the results from the entity at some later date |
¶ Ancillary |
Can be used if the subscriber uses this argument |
¶ Method |
Can be used if the subscriber uses this argument |
¶ Attribute |
Can be used if the subscriber uses this argument |
¶ Instance |
Can be used if the subscriber uses this argument |
¶ Offset |
Can be used if the subscriber uses this argument |
¶ Name |
Can be used if the subscriber uses this argument |
¶ Key |
Can be used if the subscriber uses this argument |
¶ Bytes |
Can be used if the subscriber uses this argument If you supply Bytes, you probably also want to supply Tag to indicate what is the type of that data |
¶ Parameter |
Can be used if the subscriber uses this argument |
¶ Resultant |
Can be used if the subscriber uses this argument |
¶ Index |
Can be used if the subscriber uses this argument |
¶ Count |
Can be used if the subscriber uses this argument |
¶ Aspect |
Can be used if the subscriber uses this argument |
¶ Context |
Can be used if the subscriber uses this argument |
¶ Category |
Can be used if the subscriber uses this argument |
¶ Class |
Can be used if the subscriber uses this argument |
¶ Mode |
Can be used if the subscriber uses this argument |
¶ State |
Can be used if the subscriber uses this argument |
¶ Condition |
Can be used if the subscriber uses this argument |
¶ Precedence |
Can be used if the subscriber uses this argument |
¶ Tag |
Can be used if the subscriber uses this argument Usually used to indicate the type of the data given through the Bytes argument |
¶ Time |
Can be used if the subscriber uses this argument |
¶ Timeout |
TODO - is that just something the subscriber may use as argument? We're not gonnabe waiting on anything anyway... |
¶ Authority |
Can be used if the subscriber uses this argument |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **simple usage** of the entity, therefore one can use either the entity's authority or one of the entity's authorizations. |
¶ SUBSCRIBE
The SUBSCRIBE operation is used to connect an entity to an outlet that will listen to events published on the entity (see the PUBLISH operation). The outlet itself is also an entity, and must be handled by the same server that manages the entity, otherwise an Entity error is returned.
TODO: is that true?
The subscription is recorded the entity connection lists, in its metadata.
The subscription is a one-way link, the outlet does not know how many or what entities hold a subscription to it. The subscription is optionnaly assigned an event. If an entity has multiple subscriptions, the event will be broadcast to all the subscribed outlets, only filtering out those whose subscription's Event is non null and not the same as the published event.
see PUBLISH for more details.
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a modification, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action
Click to see arguments
¶ Entity |
The entity to add a subscription on |
¶ Outlet |
The outlet that will be used as a bridge between the entity and the subscriber. The Outlet must have been activated before the connection can be made. see ACTIVATE |
¶ Event |
Filter the subscription on a specific event. The semantic of events depends on the ontology. The default is null event (`0`), which means the outlet will receive notification about any event |
¶ Precedence |
TODO J - This argument has no effect whatsoever - should that not be a thing? Doesn't every outlet get notified anyways ? Can we yoink a subscription by subscribing with a higher precedence? or does that just not have any effect? wtf is this |
¶ Timeout |
TODO: Is THAT correct? Or does A timeout to specify after how many seconds a connection should disconnect like docs.ledr.io says ???? Or maybe the timeout for remote rendez-vous? Or is it the expiry of the subscription? (see SUBSCRIPTION) Maximum wait time in seconds for the call. The timeout specifies the maximum amount of time the call is allowed to take. If the call takes longer than the timeout, the call is aborted and a Timeout error is returned. If no timeout argument is provided, a null value of |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **modification**, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action |
¶ UNSUBSCRIBE
The UNSUBSCRIBE operation is used to cancel an entity event subscription. Upon completion, any new publications of the event on the entity for the specified outlet will be ignored. If an eventargument is not specified or specified as null, all event subscriptions for the entity on the specified outlet will be canceled. If no entity event subscriptions exist for the specified subscriber, the operation has no effect
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a modification, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action
Click to see arguments
¶ Entity |
The entity we want to remove subscription from |
¶ Outlet |
The outlet we want to unsubscribe |
¶ Event |
The event of the subscription to delete. The default is null event (`0`) |
¶ Precedence |
TODO J - The precedence of a subscription has no effect anyways, is that deprecated? The precedence of the subscription to delete The default is null precedence (`0`) |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **modification**, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action |
¶ WAIT
The WAIT operation is used by subscribers to receive and process entity event notifications. Subscribers communicate with outlets via this operation. Execution of this operation awaits a queue of published entity events. As processes publish event on entities, the publications are forwarded to the outlets specified by the subscribers. At the outlet, the events are queued ona first-in/first-out basis. Subscriber processes remove notifications from the queue using the WAIT operation. This operation includes a parameter that specifies the address of the subscriber to be called upon receipt of a notification in the queue.
The subscriber will directly receive exactly the same PUBLISH request the client sent to the AvesTerra server, with the Outlet field completed by the server to indicate the Outlet the rendezvous has taken place in. Unlike when calling INVOKE/INQUIRE, the client who originated the PUBLISH does not expect to get any result back, and therefore the subscriber does not need to return anything to the server. The server simply dispatches the event and mode on to the next thing without any additional care.
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a modification, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action
Click to see arguments
¶ Outlet |
The outlet to wait on |
¶ Timeout |
TODO |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **modification**, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action |
¶ SUBSCRIPTION
The SUBSCRIPTION operation is used to get the outlet and event of a subscription of an entity at a given index.
Entity subscriptions are indexed from 1 to the total number of subscriptions the entity posseses, available through the SUBSCRIPTIONS operation.
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a simple usage of the entity, therefore one can use either the entity's authority or one of the entity's authorizations.
Click to see arguments
¶ Entity |
The entity we want to get the subscription of |
¶ Index |
The 1-based index of the subscription to get from its subscription list. If not specified or `0`, the last subscription is returned (the one created the most recently). One can get the number of subscriptions by calling SUBSCRIPTIONS |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **simple usage** of the entity, therefore one can use either the entity's authority or one of the entity's authorizations. |
¶ Lock operations
2 operations:
- LOCK
- UNLOCK
¶ LOCK
The LOCK operation is used to lock an entity lock. The operation blocks until the lock is granted, or the optional timeout has expired.
The outlet lock is a mutual exclusion synchronization mechanism in support of distributed/concurrent applications. AvesTerra uses a simple binary semaphore model. Such a semaphore is automatically allocated to every entity that is activated. This semaphore can beeither locked or unlocked. The lock can only be granted to one client application at a time, and must be unlocked before it is available to be locked again.
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a modification, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action
Click to see arguments
¶ Outlet |
The outlet to lock |
¶ Timeout |
Maximum wait time in seconds for the lock. If no timeout argument is provided, a null value of `0` is assumed, which means this operation will block forever until the lock is granted. |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **modification**, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action |
¶ UNLOCK
The UNLOCK operation is used to unlock an outlet.
Unlocking an outlet that is not locked is a no-op.
See the LOCK operation for more information about outlet locks.
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a modification, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action
Click to see arguments
¶ Outlet |
The outlet to unlock |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **modification**, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action |
¶ Authorization operations
4 operations:
- AUTHORIZE
- DEAUTHORIZE
- AUTHORIZED
- AUTHORITY
¶ AUTHORIZE
The AUTHORIZE operation is used to add an authorization to an entity. Each AvesTerra server maintains anauthorization list for every entity that it manages. The knowledge space is a shared space that can be accessed (read) by all participants. But to avoid accidental (or purposeful) knowledge creation, deletion, or misconfiguration, access restrictions may be placed on entities to limit write operations. Higher layer implementations, however, may choose to use this parameter differently to provide greater restrictions (see Restriction parameter). If the entity already has the authorization, the operation is a no-op.
One can Authorize tokens on the server's entity (using the server's Authority) to allow other authorization token to modify/create any entity
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a modification, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action
Click to see arguments
¶ Entity |
The entity to add the authorization to |
¶ Authority |
The authorization to add to the entity |
¶ Parameter |
A number to describe additional information on the authorization It will be stored alongside the authorization in the entity's metadata, and fetchable on demand so any adapter of this entity may adjust its behavior based on this additional clue about what this token is authorized to do. TODO: what does this mean? is that the new way of having a viewauthorization? then is viewauthorization deprecated? |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **modification**, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action |
¶ DEAUTHORIZE
The DEAUTHORIZE operation is used to remove an authorization from an entity.
If the entity does not have the authorization, the operation is a no-op.
See the AUTHORIZE operation for more information about authorizations.
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a modification, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action
Click to see arguments
¶ Entity |
The entity to remove the authorization from |
¶ Authority |
The authorization to remove |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **modification**, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action |
¶ AUTHORIZED
The AUTHORIZED operation is used to check if an entity has a given authorization.
See the AUTHORIZE operation for more information about authorizations.
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a simple usage of the entity, therefore one can use either the entity's authority or one of the entity's authorizations.
Click to see arguments
¶ Entity |
The entity to check the authorization of |
¶ Authority |
The authorization to check |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **simple usage** of the entity, therefore one can use either the entity's authority or one of the entity's authorizations. |
¶ AUTHORITY
The AUTHORITY operation is used to get the authority of an entity.
This call should be done using server's authority (or the entity's authority, but in that case you don't need to call this operation).
If the operation is not authorized, no_authorization is returned (the token with all bits set to 1, displayed as 'ffffffffff-ffff...')
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
For this operations the entity's authority is needed, the entity's authorizations do not have permission to perform this action
Click to see arguments
¶ Entity |
The entity to get the authority of |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. For this operations the entity's authority is needed, the entity's authorizations do not have permission to perform this action |
¶ Auxiliary operations
Except for the first operation, these are basically just getters for entity metadata.
17 operations
¶ CHANGE
Sets new value for the entity's metadata
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a modification, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action
Click to see arguments
¶ Entity |
The entity to change |
¶ Name |
The new name of the entity If empty, the name is not changed |
¶ Key |
The new key of the entity If empty, the key is not changed |
¶ Context |
The new context of the entity If 0, the context is not changed |
¶ Category |
The new category of the entity If 0, the category is not changed |
¶ Class |
The new class of the entity If 0, the class is not changed |
¶ State |
The new state of the entity If 0, the state is not changed |
¶ Authority |
The new authority of the entity If empty, the authority is not changed |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **modification**, therefore the entity's authority is needed, the entity's authorizations do not have permission to perform this action |
¶ NAME
Get the name field from the metadata of the entity.
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a simple usage of the entity, therefore one can use either the entity's authority or one of the entity's authorizations.
Click to see arguments
¶ Entity |
The entity to get the name of |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **simple usage** of the entity, therefore one can use either the entity's authority or one of the entity's authorizations. |
¶ CLASS
Get the class field from the metadata of the entity.
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a simple usage of the entity, therefore one can use either the entity's authority or one of the entity's authorizations.
Click to see arguments
¶ Entity |
The entity to get the class of |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **simple usage** of the entity, therefore one can use either the entity's authority or one of the entity's authorizations. |
¶ CATEGORY
Get the category field from the metadata of the entity.
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a simple usage of the entity, therefore one can use either the entity's authority or one of the entity's authorizations.
Click to see arguments
¶ Entity |
The entity to get the category of |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **simple usage** of the entity, therefore one can use either the entity's authority or one of the entity's authorizations. |
¶ SERVER
Get the server that manages the entity.
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a simple usage of the entity, therefore one can use either the entity's authority or one of the entity's authorizations.
Click to see arguments
¶ Entity |
The entity to get the server of |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **simple usage** of the entity, therefore one can use either the entity's authority or one of the entity's authorizations. |
¶ REDIRECTION
The REDIRECTION operation is used to get the real EUID of an entity.
If the given entity is a redirection, the destination entity is returned.
Otherwise, the given entity is returned.
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a simple usage of the entity, therefore one can use either the entity's authority or one of the entity's authorizations.
Click to see arguments
¶ Entity |
The entity to get the real EUID of |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **simple usage** of the entity, therefore one can use either the entity's authority or one of the entity's authorizations. |
¶ TIMESTAMP
Get the timestamp field from the metadata of the entity.
This timestamp represents the time at which the entity was created
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a simple usage of the entity, therefore one can use either the entity's authority or one of the entity's authorizations.
Click to see arguments
¶ Entity |
The entity to get the timestamp of |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **simple usage** of the entity, therefore one can use either the entity's authority or one of the entity's authorizations. |
¶ AVAILABLE
Get the network availability of the entity.
TODO: what does that mean? Is that a ping?
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a simple usage of the entity, therefore one can use either the entity's authority or one of the entity's authorizations.
Click to see arguments
¶ Entity |
The entity to get the network availability of |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **simple usage** of the entity, therefore one can use either the entity's authority or one of the entity's authorizations. |
¶ EXTINCT
The EXTINCT operation is used to check if an entity is extinct.
An entity is extinct if it has been deleted, see DELETE.
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a simple usage of the entity, therefore one can use either the entity's authority or one of the entity's authorizations.
Click to see arguments
¶ Entity |
The entity to get the extinct status of |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **simple usage** of the entity, therefore one can use either the entity's authority or one of the entity's authorizations. |
¶ ACTIVATED
The ACTIVATED operation is used to check if an entity is activated.
see ACTIVATE
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a simple usage of the entity, therefore one can use either the entity's authority or one of the entity's authorizations.
Click to see arguments
¶ Entity |
The entity to get the activation status of |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **simple usage** of the entity, therefore one can use either the entity's authority or one of the entity's authorizations. |
¶ LOCKED
The LOCKED operation is used to check if an entity is locked.
Note that by the time the response reaches you, its lock status may have changed
see LOCK
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a simple usage of the entity, therefore one can use either the entity's authority or one of the entity's authorizations.
Click to see arguments
¶ Entity |
The entity to get the lock status of |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **simple usage** of the entity, therefore one can use either the entity's authority or one of the entity's authorizations. |
¶ PENDING
The PENDING operation is used to get the number of invoke and inquire currently in queue on the entity.
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a simple usage of the entity, therefore one can use either the entity's authority or one of the entity's authorizations.
Click to see arguments
¶ Entity |
The entity to get the number of invoke and inquire currently in queue of |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **simple usage** of the entity, therefore one can use either the entity's authority or one of the entity's authorizations. |
¶ RENDEZVOUS
The RENDEZVOUS operation is used to get the state of an entitys' rendezvous
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a simple usage of the entity, therefore one can use either the entity's authority or one of the entity's authorizations.
Click to see arguments
¶ Entity |
The entity to get the rendezvous state of |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **simple usage** of the entity, therefore one can use either the entity's authority or one of the entity's authorizations. |
¶ REFERENCES
The REFERENCES operation is used to get the current reference count of an entity
see REFERENCE
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a simple usage of the entity, therefore one can use either the entity's authority or one of the entity's authorizations.
Click to see arguments
¶ Entity |
The entity to get the reference count of |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **simple usage** of the entity, therefore one can use either the entity's authority or one of the entity's authorizations. |
¶ CONNECTIONS
The CONNECTIONS operation is used to get the current number of connections of an entity
see CONNECT
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a simple usage of the entity, therefore one can use either the entity's authority or one of the entity's authorizations.
Click to see arguments
¶ Entity |
The entity to get the number of connection of |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **simple usage** of the entity, therefore one can use either the entity's authority or one of the entity's authorizations. |
¶ ATTACHMENTS
The ATTACHMENTS operation is used to get the current number of attachments of an entity
see ATTACH
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a simple usage of the entity, therefore one can use either the entity's authority or one of the entity's authorizations.
Click to see arguments
¶ Entity |
The entity to get the number of attachments of |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **simple usage** of the entity, therefore one can use either the entity's authority or one of the entity's authorizations. |
¶ SUBSCRIPTIONS
The SUBSCRIPTIONS operation is used to get the current number of subscriptions of an entity
see SUBSCRIBE
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a simple usage of the entity, therefore one can use either the entity's authority or one of the entity's authorizations.
Click to see arguments
¶ Entity |
The entity to get the current number of subscriptions of |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **simple usage** of the entity, therefore one can use either the entity's authority or one of the entity's authorizations. |
¶ AUTHORIZATIONS
The AUTHORIZATIONS operation is used to get the current number of authorizations of an entity
see AUTHORIZE
Authorization: Like all operations, either the server's Authority or one of its authorization is also allowed to perform it.
This operations counts as a simple usage of the entity, therefore one can use either the entity's authority or one of the entity's authorizations.
Click to see arguments
¶ Entity |
The entity to get the current number of authorizations of |
¶ Authorization |
Like all operations, either the server's Authority or one of its authorization is also allowed to perform it. This operations counts as a **simple usage** of the entity, therefore one can use either the entity's authority or one of the entity's authorizations. |