dido:public:s_cli:05_contents:01_prt:02_basics:02_solstack:didostack:start
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
dido:public:s_cli:05_contents:01_prt:02_basics:02_solstack:didostack:start [2021/08/09 12:41] murphy |
dido:public:s_cli:05_contents:01_prt:02_basics:02_solstack:didostack:start [2021/08/18 11:40] (current) murphy |
||
|---|---|---|---|
| Line 2: | Line 2: | ||
| [[dido:public:s_cli:05_contents:01_prt:02_basics:start| Return to DIDO CLI Background]] | [[dido:public:s_cli:05_contents:01_prt:02_basics:start| Return to DIDO CLI Background]] | ||
| - | The proposed DIDO Solution Stack is modeled after the [[dido:public:s_cli:05_contents:01_prt:02_basics:02_solstack:dbstack:start| Database Solution Stack]]. The core features of both stacks is persistent storage of data and the modification of data using [[dido:public:ra:1.2_views:2_tech_views:2-nodenet:3_nodearch:2_ido:2_trans | Transaction]]. The major difference is that the DIDO [[dido:public:ra:xapend:xapend.a_glossary:d:data_object|data objects]] Transactions are journaled with each Transaction being distributed to all the nodes in the node network. The details about how the Transactions are bundled, validated and verified vary amongst [[dido:public:ra:1.2_views:2_tech_views:2-nodenet:2_node:3_platform | DIDO platforms]]. For example, some platforms bundle the Transactions into a block and the block is distributed once it has been verified by a mining operation. Others use "neighboring" nodes to valid and verify the Transactions. | + | The proposed DIDO [[dido:public:ra:xapend:xapend.a_glossary:s:solutionstack|Solution Stack]] is modeled after the [[dido:public:s_cli:05_contents:01_prt:02_basics:02_solstack:dbstack:start| Database Solution Stack]]. The core features of both stacks is persistent storage of data and the modification of data using [[dido:public:ra:1.2_views:2_tech_views:2-nodenet:3_nodearch:2_ido:2_trans | Transaction]]. The major difference is that the DIDO [[dido:public:ra:xapend:xapend.a_glossary:d:data_object|data objects]] Transactions are journaled with each Transaction being distributed to all the [[dido:public:ra:xapend:xapend.a_glossary:n:node|nodes]] in the [[dido:public:ra:xapend:xapend.a_glossary:n:node_network|node network]]. The details about how the Transactions are bundled, validated and verified vary amongst [[dido:public:ra:1.2_views:2_tech_views:2-nodenet:2_node:3_platform | DIDO platforms]]. For example, some [[dido:public:ra:xapend:xapend.a_glossary:p:platform|platforms]] bundle the Transactions into a block and the block is distributed once it has been verified by a [[dido:public:ra:xapend:xapend.a_glossary:m:mining|mining]] operation. Others use "neighboring" nodes to valid and verify the Transactions. |
| <figure> | <figure> | ||
| Line 12: | Line 12: | ||
| * **[[dido:public:ra:xapend:xapend.a_glossary:a:application|Application]]** - The Application is similar to the Application in the [[dido:public:s_cli:05_contents:01_prt:02_basics:02_solstack:dbstack:start| Database Solution Stack]], is the application, program, utility, service or microservice that needs to interact with the DIDO. This is done using standardized DIDO [[dido:public:ra:xapend:xapend.a_glossary:d:ddl]] or [[dido:public:ra:xapend:xapend.a_glossary:d:dml]] using textual commands that adhere to the DIDO-CLI specifications See: [[dido:public:ra:xapend:xapend.b_stds:tech:iso:dblang_sql_part1]] and related specifications. | * **[[dido:public:ra:xapend:xapend.a_glossary:a:application|Application]]** - The Application is similar to the Application in the [[dido:public:s_cli:05_contents:01_prt:02_basics:02_solstack:dbstack:start| Database Solution Stack]], is the application, program, utility, service or microservice that needs to interact with the DIDO. This is done using standardized DIDO [[dido:public:ra:xapend:xapend.a_glossary:d:ddl]] or [[dido:public:ra:xapend:xapend.a_glossary:d:dml]] using textual commands that adhere to the DIDO-CLI specifications See: [[dido:public:ra:xapend:xapend.b_stds:tech:iso:dblang_sql_part1]] and related specifications. | ||
| - | * **Users** - And end user can enter DIDO compliant DDDL or DDML text commands into a terminal or even produce scripts that contain a series of commands that sent to the Open DIDO Connectivity [[dido:public:ra:xapend:xapend.a_glossary:a:api|API]] (ODAPI)for processing. Just as with the Application, these commands need to be compliant with the proposed Standard See: [[dido:public:s_cli:05_contents:01_prt:04_dll:start]], [[dido:public:s_cli:05_contents:01_prt:06_dddl:start]], and [[dido:public:s_cli:05_contents:01_prt:09_dml]]. | + | * **Users** - And end user can enter DIDO compliant DDDL or DDML text commands into a terminal or even produce [[dido:public:ra:xapend:xapend.a_glossary:s:script|scripts]] that contain a series of commands that sent to the Open DIDO Connectivity [[dido:public:ra:xapend:xapend.a_glossary:a:api|API]] (ODAPI)for processing. Just as with the Application, these commands need to be compliant with the proposed Standard See: [[dido:public:s_cli:05_contents:01_prt:04_dll:start]], [[dido:public:s_cli:05_contents:01_prt:06_dddl:start]], and [[dido:public:s_cli:05_contents:01_prt:09_dml]]. |
| * **Open DIDO Connectivity API (Open DIDO Data Binary Connectivity Layer (ODDBCL)** - This a utility (i.e., usually a library) that the application calls to process the DIDO-CLI commands and check for validity and verification that the commands are correct. | * **Open DIDO Connectivity API (Open DIDO Data Binary Connectivity Layer (ODDBCL)** - This a utility (i.e., usually a library) that the application calls to process the DIDO-CLI commands and check for validity and verification that the commands are correct. | ||
| - | * **DIDO Data Definition Language (DDDL)** - The DIDO Data Definition Language (DDDL) is used to create and modify the structure of DIDO objects in a DIDO. These DIDO objects include Types, objects, oracles, exchanges, aggregates, and smart contracts, etc. Often, the DDDL commands require a different set of privileges than the DIDO Data Manipulation Language (DDML). | + | * **DIDO Data Definition Language (DDDL)** - The DIDO Data Definition Language (DDDL) is used to create and modify the structure of DIDO [[dido:public:ra:xapend:xapend.a_glossary:o:object|objects]] in a DIDO. These DIDO objects include Types, objects, oracles, exchanges, aggregates, and smart contracts, etc. Often, the DDDL commands require a different set of [[dido:public:ra:xapend:xapend.a_glossary:p:privileges|privileges]] than the DIDO Data Manipulation Language (DDML). |
| * **DIDO Data Manipulation Language (DDML)** - The DIDO Data Manipulation Language (DDML) includes commands permitting users to manipulate (i.e., read) data in a DIDO. Note, the Data in the DIDO is [[dido:public:ra:xapend:xapend.a_glossary:i:immutable|immutable]]. This manipulation involves inserting data into DIDO Objects, making for deletion objects, creating a Transaction to update the objects and associated data from different objects together. | * **DIDO Data Manipulation Language (DDML)** - The DIDO Data Manipulation Language (DDML) includes commands permitting users to manipulate (i.e., read) data in a DIDO. Note, the Data in the DIDO is [[dido:public:ra:xapend:xapend.a_glossary:i:immutable|immutable]]. This manipulation involves inserting data into DIDO Objects, making for deletion objects, creating a Transaction to update the objects and associated data from different objects together. | ||
| - | * **DIDO Drivers** - The DIDO [[dido:public:ra:xapend:xapend.a_glossary:d:dbdriver | Drivers ]] are computer programs that implements a protocol (i.e., ODDBCL) for a DIDO connection. | + | * **DIDO Drivers** - The DIDO [[dido:public:ra:xapend:xapend.a_glossary:d:dbdriver | Drivers ]] are computer programs that implements a [[dido:public:ra:xapend:xapend.a_glossary:p:protocol|protocol]] (i.e., ODDBCL) for a DIDO connection. |
| - | * **DIDO Data Management System (DDMS) ** - The DIDO Data Management System is a software package designed to define, manipulate, retrieve and manage DIDO Objects in a DIDO. A DIDO generally manipulates the objects itself, the object format, field names, object structure. It also defines rules to validate and manipulate this data. | + | * **DIDO Data Management System (DDMS) ** - The DIDO Data Management System is a software package designed to define, manipulate, retrieve and manage DIDO [[dido:public:ra:xapend:xapend.a_glossary:o:object|Objects]] in a DIDO. A DIDO generally manipulates the objects itself, the object format, field names, object structure. It also defines rules to validate and manipulate this data. |
| * **DIDO Data Command Line Interpreter (DDCLI)** - The Command Line Interpreter translates the tokenized DIDO commands into DIDO Platform Specific instructions. | * **DIDO Data Command Line Interpreter (DDCLI)** - The Command Line Interpreter translates the tokenized DIDO commands into DIDO Platform Specific instructions. | ||
| * **DIDO Platform CLI** - Sme DIDO platforms offer their own proprietary CLI. There have been efforts to "re-use" a particular DIDO Platform CLI on different Platforms. | * **DIDO Platform CLI** - Sme DIDO platforms offer their own proprietary CLI. There have been efforts to "re-use" a particular DIDO Platform CLI on different Platforms. | ||
| * **DIDO API** - Many DIDO Platforms provide [[dido:public:ra:xapend:xapend.a_glossary:a:api|APIs]] allowing a programmer to directly access a DIDO. For example, [[dido:public:ra:xapend:xapend.a_glossary:e:ethereum|Ethereum]] provides a __Javascript API Libraures__, [[https://ethereum.org/en/developers/docs/apis/javascript/]] or __Ethereum JSON RPC__, [[https://ethereumbuilders.gitbooks.io/guide/content/en/ethereum_json_rpc.html]]. | * **DIDO API** - Many DIDO Platforms provide [[dido:public:ra:xapend:xapend.a_glossary:a:api|APIs]] allowing a programmer to directly access a DIDO. For example, [[dido:public:ra:xapend:xapend.a_glossary:e:ethereum|Ethereum]] provides a __Javascript API Libraures__, [[https://ethereum.org/en/developers/docs/apis/javascript/]] or __Ethereum JSON RPC__, [[https://ethereumbuilders.gitbooks.io/guide/content/en/ethereum_json_rpc.html]]. | ||
| - | * **DIDO Configuration** - There are always two aspects to configuring a DIDO. The first is setting up the environment externally to the DIDO Platform (i.e., downloading the software, running a wizard to install and configure the DIDO, etc), the second is the startup, upgrade, shutdown, etc of the DIDO Platform. | + | * **DIDO Configuration** - There are always two aspects to configuring a DIDO. The first is setting up the environment externally to the DIDO Platform (i.e., downloading the software, running a [[dido:public:ra:xapend:xapend.a_glossary:w:wizard|wizard]] to install and configure the DIDO, etc), the second is the startup, upgrade, shutdown, etc of the DIDO Platform. |
| * **DIDO Data Definition** - A DIDO provides a way to define Types, objects, oracles, exchanges, aggregates, and smart contracts, etc. to the DIDO. | * **DIDO Data Definition** - A DIDO provides a way to define Types, objects, oracles, exchanges, aggregates, and smart contracts, etc. to the DIDO. | ||
| * **DIDO Data Manipulation** - A DIDO provides a way to manipulate the inserting data into DIDO Objects, making for deletion objects, creating a Transaction to update the objects and associated data from different objects together. | * **DIDO Data Manipulation** - A DIDO provides a way to manipulate the inserting data into DIDO Objects, making for deletion objects, creating a Transaction to update the objects and associated data from different objects together. | ||
| Line 58: | Line 58: | ||
| ^ Properties ^ [[dido:public:ra:xapend:xapend.a_glossary:s:static_library]] ^ [[dido:public:ra:xapend:xapend.a_glossary:s:shared_libraries]] ^ | ^ Properties ^ [[dido:public:ra:xapend:xapend.a_glossary:s:static_library]] ^ [[dido:public:ra:xapend:xapend.a_glossary:s:shared_libraries]] ^ | ||
| ^ Linking time | It happens as the last step of the compilation process. After the program is placed in the memory | Shared libraries are added during linking process when [[dido:public:ra:xapend:xapend.a_glossary:e:exec|executable file]] and libraries are added to the memory. | | ^ Linking time | It happens as the last step of the compilation process. After the program is placed in the memory | Shared libraries are added during linking process when [[dido:public:ra:xapend:xapend.a_glossary:e:exec|executable file]] and libraries are added to the memory. | | ||
| - | ^ Means | Performed by linkers | Performed by operating System | | + | ^ Means | Performed by linkers | Performed by [[dido:public:ra:xapend:xapend.a_glossary:o:os|operating system]] | |
| ^ Size | Static libraries are much bigger in size, because external programs are built in the executable file. | Dynamic libraries are much smaller, because there is only one copy of dynamic library that is kept in memory. | | ^ Size | Static libraries are much bigger in size, because external programs are built in the executable file. | Dynamic libraries are much smaller, because there is only one copy of dynamic library that is kept in memory. | | ||
| ^ External file changes | Executable file will have to be recompiled if any changes were applied to external files. | In shared libraries, no need to recompile the executable. | | ^ External file changes | Executable file will have to be recompiled if any changes were applied to external files. | In shared libraries, no need to recompile the executable. | | ||
| ^ Time | Takes longer to execute, because loading into the memory happens every time while executing. | It is faster because shared library code is already in the memory. | | ^ Time | Takes longer to execute, because loading into the memory happens every time while executing. | It is faster because shared library code is already in the memory. | | ||
| - | ^ Compatibility | Never has compatibility issue, since all code is in one executable module. | Programs are dependent on having a compatible library. Dependent program will not work if library gets removed from the system. | | + | ^ Compatibility | Never has compatibility issue, since all code is in one executable [[dido:public:ra:xapend:xapend.a_glossary:m:module|module]]. | Programs are dependent on having a compatible library. Dependent program will not work if library gets removed from the system. | |
| </table> | </table> | ||
| Line 71: | Line 71: | ||
| - | Naturally, many of these APIs are focused on [[dido:public:ra:xapend:xapend.a_glossary:r:rest]] over [[dido:public:ra:xapend:xapend.a_glossary:h:http]] types of [[dido:public:ra:xapend:xapend.a_glossary:i:interface|interfaces]] that define the standardized set of actions or verbs (i.e., GET, POST, PUT, DELETE, PATCH) as part of the [[dido:public:ra:xapend:xapend.a_glossary:h:http_request]] of what needs to be done, not the actual "what" needs to be acted upon. The what is usually sent along as a standardized document (payload) as [[dido:public:ra:xapend:xapend.b_stds:tech:w3c:xml | Extensible Markup Language (XML) ]] or [[dido:public:ra:xapend:xapend.b_stds:tech:ietf:json | JSON]]. also, sometimes the HTTP Request Header is used to send information to the service. The Header is a set of key-value pairs with no or little standardization as the what keys are to be returned nor what the values are. ER-20 | + | Naturally, many of these APIs are focused on [[dido:public:ra:xapend:xapend.a_glossary:r:rest]] over [[dido:public:ra:xapend:xapend.a_glossary:h:http]] types of [[dido:public:ra:xapend:xapend.a_glossary:i:interface|interfaces]] that define the standardized set of actions or verbs (i.e., GET, POST, PUT, DELETE, PATCH) as part of the [[dido:public:ra:xapend:xapend.a_glossary:h:http_request]] of what needs to be done, not the actual "what" needs to be acted upon. The what is usually sent along as a standardized document (payload) as [[dido:public:ra:xapend:xapend.b_stds:tech:w3c:xml | Extensible Markup Language (XML) ]] or [[dido:public:ra:xapend:xapend.b_stds:tech:ietf:json | JSON]]. also, sometimes the HTTP Request Header is used to send information to the service. The Header is a set of [[dido:public:ra:xapend:xapend.a_glossary:k:key|key]]-value pairs with no or little standardization as the what keys are to be returned nor what the values are. ER-20 |
| There is a similar problem with the [[dido:public:ra:xapend:xapend.a_glossary:h:http_response]]. Although the document (payload) that is returned is in a standardized XML or JSON format, the contents of the document are not standardized. Some HTTP Responses send the results back as part of the HTTP Header which is comprised of non-standardized key-value pairs. Some examples of standardization efforts are the [[dido:public:ra:xapend:xapend.a_glossary:d:defactostd]] [[dido:public:ra:xapend:xapend.b_stds:defact:ethereum:eip:erc_0020 | ERC-20]] and the [[https://reference.niem.gov/niem/guidance/iepd-requirements/2.1/iepd-requirements-2.1.pdf | Government Standard National Information Exchange Model (NIEM) Information Exchange Package Documentation (IEPD) Specification]]. | There is a similar problem with the [[dido:public:ra:xapend:xapend.a_glossary:h:http_response]]. Although the document (payload) that is returned is in a standardized XML or JSON format, the contents of the document are not standardized. Some HTTP Responses send the results back as part of the HTTP Header which is comprised of non-standardized key-value pairs. Some examples of standardization efforts are the [[dido:public:ra:xapend:xapend.a_glossary:d:defactostd]] [[dido:public:ra:xapend:xapend.b_stds:defact:ethereum:eip:erc_0020 | ERC-20]] and the [[https://reference.niem.gov/niem/guidance/iepd-requirements/2.1/iepd-requirements-2.1.pdf | Government Standard National Information Exchange Model (NIEM) Information Exchange Package Documentation (IEPD) Specification]]. | ||
| Line 88: | Line 88: | ||
| </figure> | </figure> | ||
| - | In the third scenario, an application uses a DIDO Platform specific library that specifically supports the coding language requires of the application (i.e., [[dido:public:ra:xapend:xapend.a_glossary:j:javascript|Javascript]], Python, Java, etc) to interact with the DIDO Platform generally these languages are imbedded in Web Pages or can be used within the language specific applications. The application can be a thicker client or a lightweight browser application. The client talks to the server usually [[dido:public:ra:xapend:xapend.b_stds:tech:w3c:xml | XML]] or more recently [[dido:public:ra:xapend:xapend.b_stds:tech:ietf:json | JSON]]. | + | In the third scenario, an application uses a DIDO Platform specific library that specifically supports the coding language requires of the application (i.e., [[dido:public:ra:xapend:xapend.a_glossary:j:javascript|Javascript]], Python, Java, etc) to interact with the DIDO Platform generally these languages are imbedded in Web Pages or can be used within the language specific applications. The application can be a thicker client or a lightweight browser application. The client talks to the [[dido:public:ra:xapend:xapend.a_glossary:s:server|server]] usually [[dido:public:ra:xapend:xapend.b_stds:tech:w3c:xml | XML]] or more recently [[dido:public:ra:xapend:xapend.b_stds:tech:ietf:json | JSON]]. |
| <figure applicationServerModel> | <figure applicationServerModel> | ||
dido/public/s_cli/05_contents/01_prt/02_basics/02_solstack/didostack/start.1628527261.txt.gz · Last modified: 2021/08/09 12:41 by murphy
