From 1925462202cbeec91f109559b825fde9c00f06f0 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Tue, 23 Jun 2020 19:28:29 +0530 Subject: [PATCH 01/34] Update README.md --- README.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 7dc24b1..9917673 100644 --- a/README.md +++ b/README.md @@ -608,8 +608,9 @@ Parameters while resetting or updating ## 5. Application Data -### DEPRECATED - Application data system is a legacy data field without vector clock support in options. In our development process, General Data was created by adding vector clock support to application data at user level. So SEND and REQUEST options in Application Data are exactly the same as General data without vector clock options +However, since Application Data system has no vector clock support in SEND and REQUEST OPTIONS, it will always give the entire data set stored in the cloud since start, and user will have to custom handle the output of it himself. Our client side framework will not stoe it for the user. + +Usually ObjectData and GeneralData systems will support most of user needs. But for cases when the user wants the entire cloud data set, and no client side framework handling, he should use ApplicationData From ee267bc31d70d66d40e78b064044d1a39d3d8360 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Tue, 23 Jun 2020 19:32:49 +0530 Subject: [PATCH 02/34] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 9917673..a5ba027 100644 --- a/README.md +++ b/README.md @@ -612,5 +612,5 @@ Application data system is a legacy data field without vector clock support in o However, since Application Data system has no vector clock support in SEND and REQUEST OPTIONS, it will always give the entire data set stored in the cloud since start, and user will have to custom handle the output of it himself. Our client side framework will not stoe it for the user. -Usually ObjectData and GeneralData systems will support most of user needs. But for cases when the user wants the entire cloud data set, and no client side framework handling, he should use ApplicationData +Usually ObjectData and GeneralData systems will support most of user needs. But for cases when the user wants the entire cloud data set, and no client side framework handling, he should use ApplicationData. Although Application Data system supports lower vectorClock as a REQUEST option. If lower vectorClock is specified, it will give all cloud stored application data after that vectorClock. From e7fcd3dd0e8f0bc14ea72388ad542a497f42394e Mon Sep 17 00:00:00 2001 From: tripathyr Date: Tue, 23 Jun 2020 19:48:38 +0530 Subject: [PATCH 03/34] Update README.md --- README.md | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index a5ba027..d63a71b 100644 --- a/README.md +++ b/README.md @@ -608,9 +608,20 @@ Parameters while resetting or updating ## 5. Application Data +#### Philosophy Application data system is a legacy data field without vector clock support in options. In our development process, General Data was created by adding vector clock support to application data at user level. So SEND and REQUEST options in Application Data are exactly the same as General data without vector clock options -However, since Application Data system has no vector clock support in SEND and REQUEST OPTIONS, it will always give the entire data set stored in the cloud since start, and user will have to custom handle the output of it himself. Our client side framework will not stoe it for the user. +Even ObjectData was created over Application Data. ObjectData is a special construction provided by framework so that Javacript objects can directly be stored and retrieved from the cloud -Usually ObjectData and GeneralData systems will support most of user needs. But for cases when the user wants the entire cloud data set, and no client side framework handling, he should use ApplicationData. Although Application Data system supports lower vectorClock as a REQUEST option. If lower vectorClock is specified, it will give all cloud stored application data after that vectorClock. +#### Vector Clock issues in Application Data +Application data supports Vector clock in REQUEST option, but it is not mandatory. Since Application Data system has no mandatory vector clock requirement in REQUEST OPTIONS, it will always give the entire data set stored in the cloud since start if invoked without vectorClock, and user will have to custom handle the request output himself at client end. Our client side framework will not store it for the user. +Usually ObjectData and GeneralData systems will support most of user needs. But for cases when the user wants the entire cloud data set, and no client side framework handling, he should use ApplicationData. Although Application Data system supports lower vectorClock, upper vectorClock, at vectorClock and mostRecentvectorClock as a REQUEST option. + +If lower vectorClock is specified, it will give all cloud stored application data after that vectorClock. +If upper vectorClock is specified, it will give all cloud stored application data before that vectorClock. +If at vectorClock is specified, it will give cloud stored application data exactly at that vectorClock. +If most recent vectorClock is specified, it will give just the last stored application data. + +#### No local IDB storage +Application Data results are not stored in local IndexedDB by Standard Operations Framework. From 33ec57cea118f735ed0872f24af0ebac3bff0449 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Tue, 23 Jun 2020 19:52:57 +0530 Subject: [PATCH 04/34] Update README.md --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index d63a71b..952cfe8 100644 --- a/README.md +++ b/README.md @@ -609,9 +609,9 @@ Parameters while resetting or updating ## 5. Application Data #### Philosophy -Application data system is a legacy data field without vector clock support in options. In our development process, General Data was created by adding vector clock support to application data at user level. So SEND and REQUEST options in Application Data are exactly the same as General data without vector clock options +Application data system is original data field system that we created for our cloud. It does not integrate with local IDB storage and synchronization in the browser. In our development process, General Data was created by adding vector clock support to application data at browser level to synchronize cloud and local IDB. SEND and REQUEST options in Application Data are exactly the same as General data without vector clock IDB local storage support at browser level. -Even ObjectData was created over Application Data. ObjectData is a special construction provided by framework so that Javacript objects can directly be stored and retrieved from the cloud +Even ObjectData was created on top of Application Data. ObjectData is a special construction provided by framework so that Javacript objects can directly be stored and retrieved from the cloud #### Vector Clock issues in Application Data Application data supports Vector clock in REQUEST option, but it is not mandatory. Since Application Data system has no mandatory vector clock requirement in REQUEST OPTIONS, it will always give the entire data set stored in the cloud since start if invoked without vectorClock, and user will have to custom handle the request output himself at client end. Our client side framework will not store it for the user. From f23dd9e6e88544b3006761242e65c0cfde8ba4bf Mon Sep 17 00:00:00 2001 From: tripathyr Date: Tue, 23 Jun 2020 19:53:38 +0530 Subject: [PATCH 05/34] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 952cfe8..064c3ec 100644 --- a/README.md +++ b/README.md @@ -621,7 +621,7 @@ Usually ObjectData and GeneralData systems will support most of user needs. But If lower vectorClock is specified, it will give all cloud stored application data after that vectorClock. If upper vectorClock is specified, it will give all cloud stored application data before that vectorClock. If at vectorClock is specified, it will give cloud stored application data exactly at that vectorClock. -If most recent vectorClock is specified, it will give just the last stored application data. +If most recent vectorClock is set as true, it will give just the last stored application data. #### No local IDB storage Application Data results are not stored in local IndexedDB by Standard Operations Framework. From 4f91a3e44e1ff35ae4f09f8987556ec8ac0b3ac5 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Tue, 23 Jun 2020 19:57:55 +0530 Subject: [PATCH 06/34] Update README.md --- README.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 064c3ec..10ac547 100644 --- a/README.md +++ b/README.md @@ -618,10 +618,11 @@ Application data supports Vector clock in REQUEST option, but it is not mandator Usually ObjectData and GeneralData systems will support most of user needs. But for cases when the user wants the entire cloud data set, and no client side framework handling, he should use ApplicationData. Although Application Data system supports lower vectorClock, upper vectorClock, at vectorClock and mostRecentvectorClock as a REQUEST option. -If lower vectorClock is specified, it will give all cloud stored application data after that vectorClock. -If upper vectorClock is specified, it will give all cloud stored application data before that vectorClock. -If at vectorClock is specified, it will give cloud stored application data exactly at that vectorClock. -If most recent vectorClock is set as true, it will give just the last stored application data. +* If lower vectorClock is specified, it will give all cloud stored application data after that vectorClock. +* If upper vectorClock is specified, it will give all cloud stored application data before that vectorClock. +* If at vectorClock is specified, it will give cloud stored application data exactly at that vectorClock. +* If most recent vectorClock is set as true, it will give just the last stored application data. +* If no vectorClock is specified, it will give all the data stored in cloud #### No local IDB storage Application Data results are not stored in local IndexedDB by Standard Operations Framework. From ee26c7393659b3d168861a3efea359a984faa27f Mon Sep 17 00:00:00 2001 From: tripathyr Date: Tue, 23 Jun 2020 19:59:09 +0530 Subject: [PATCH 07/34] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 10ac547..e083192 100644 --- a/README.md +++ b/README.md @@ -604,7 +604,7 @@ Parameters while resetting or updating * `lowerVectorClock` - VC from which the data is to be requested * `upperVectorClock` - VC till which the data is to be requested * `atVectorClock` - VC at which the data is to requested - * `mostRecent` - boolean (true: request only the recent data matching the pattern) + * `mostRecent` - boolean (true: request only the recent data matching the pattern. Just the last one.) ## 5. Application Data From 754738f06f4f81078c2fe0f4dce8501da3c7cf2f Mon Sep 17 00:00:00 2001 From: tripathyr Date: Tue, 23 Jun 2020 20:08:13 +0530 Subject: [PATCH 08/34] Update README.md --- README.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index e083192..64e801d 100644 --- a/README.md +++ b/README.md @@ -569,19 +569,22 @@ Parameters while sending * `receiverID` - receiver of the data * `application` - application using the data * `comment` - user comment of the data + +##### Important: Never use senderIDs in SEND DATA options. The system automatically picks the FLO ID of the sender from FLO Globals. Its a common mistake developers make. + ### REQUEST DATA #### request options - * `receiverID` - receiver of the data - * `type` - type of the data ( a free user field) + * `receiverID` - receiver FLO ID of the data + * `type` - type of the data ( a free user field that sender might have used in SEND DATA phase) * `senderIDs` - array of senderIDs * `application` - application of the data * `comment` - comment of the data * `lowerVectorClock` - VC from which the data is to be requested * `upperVectorClock` - VC till which the data is to be requested * `atVectorClock` - VC at which the data is to requested - * `mostRecent` - boolean (true: request only the recent data matching the pattern) + * `mostRecent` - boolean (true: request only the recent data matching the pattern. Just the last one) ## 5. ObjectData @@ -590,14 +593,15 @@ Parameters while resetting or updating * `Object Data` #### Options - * `receiverID` - receiver of the data + * `receiverID` - receiver FLO ID of the data * `application` - application using the data * `comment` - comment of the data +##### Important: Never use senderIDs in RESET and UPDATE. The system automatically picks the FLO ID of the sender from FLO Globals. Its a common mistake developers make. ### REQUEST DATA #### request options - * `receiverID` - receiver of the data + * `receiverID` - receiver FLO ID of the data * `senderIDs` - array of senderIDs * `application` - application of the data * `comment` - comment of the data From 14d54c20469a0d0b120e89c77826da8e6eb146a8 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Tue, 23 Jun 2020 20:19:01 +0530 Subject: [PATCH 09/34] Update README.md --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index 64e801d..711513e 100644 --- a/README.md +++ b/README.md @@ -610,6 +610,8 @@ Parameters while resetting or updating * `atVectorClock` - VC at which the data is to requested * `mostRecent` - boolean (true: request only the recent data matching the pattern. Just the last one.) +##### Important: Type field is never used while RESET, UPDATE or REQUEST operations in Object Data. Type field is internally blocked for Object Data. + ## 5. Application Data #### Philosophy From 25424b94769dd3b0b217b02f4ab2026c912809bd Mon Sep 17 00:00:00 2001 From: tripathyr Date: Tue, 23 Jun 2020 20:21:57 +0530 Subject: [PATCH 10/34] Update README.md --- README.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/README.md b/README.md index 711513e..34292f1 100644 --- a/README.md +++ b/README.md @@ -432,6 +432,11 @@ Note: value of objectData is taken from floGlobals 2. addList - Array of subAdmins to add 3. rmList - Array of subAdmins to remove + +* Example: floDapps.manageSubAdmins(adminPrivKey, [addr1, addr2..]) to add addr1 and addr2 as subAdmin +* Example: floDapps.manageSubAdmins(adminPrivKey, null, [addr1, addr2..]) to remove addr1 and addr2 as subAdmin + + #### clearCredentials floDapps.clearCredentials() `clearCredentials` removes the login credentials stored in IDB. From 8e61606de79d7ca18c34093bd0052caefa9567c7 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Tue, 23 Jun 2020 20:33:29 +0530 Subject: [PATCH 11/34] Update README.md --- README.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/README.md b/README.md index 34292f1..ebe7e8f 100644 --- a/README.md +++ b/README.md @@ -95,6 +95,8 @@ This template contains standard operations that can be used for the following: ## FLO Crypto Operations `floCrypto` operations can be used to perform blockchain-cryptography methods. `floCrypto` operations are synchronized and return a value. Contains the following Operations. +#### Important: FLO Crypto operations are all functions. They have not been promisified + #### Generate New FLO ID pair floCrypto.generateNewID() `generateNewID` generates a new flo ID and returns private-key, public-key and floID @@ -193,6 +195,8 @@ This template contains standard operations that can be used for the following: ## FLO Blockchain API Operations `floBlockchainAPI` object method can be used to send/recieve data to/from blockchain. These functions are asynchronous and return a promise. Contains the following functions. +#### Important: FLO Blockchain API operations have all been promisified. All output needs to be handled using .then These operations do not return function return values. Once again, they resolve do not return. + #### promisedAJAX floBlockchainAPI.promisedAJAX(method, uri) `promisedAJAX` requests data using API @@ -283,6 +287,8 @@ Note: If passed as Array, then ratio of the balance of the senders are preserved ## Compact IndexedDB operations `compactIDB` operations can be used to perform basic IndexedDB operations such as add, read/write, modify and remove.Contains following operations. +#### Important: Compact IndexedDB operations have all been promisified. All output needs to be handled using .then These operations do not return function return values. Once again, they resolve do not return. + #### setDefaultDB compactIDB.setDefaultDB(dbName) `setDefaultDB` sets the database on which further operations will be performed. @@ -352,6 +358,8 @@ This module contains functions that interact with the supernode to send and retr ## FLO Cloud API operations `floCloudAPI` operations can interact with floSupernode cloud to send and retrieve data for applications. floCloudAPI uses floSupernode module for backend interactions. +#### Important: FLO Cloud API operations have all been promisified. All output needs to be handled using .then These operations do not return function return values. Once again, they resolve do not return. + #### sendApplicationData floCloudAPI.sendApplicationData(message, type, options = {}) `sendApplicationData` sends application data to the cloud. From a33e79a8d09e03798a97e26bb70ad666e9e04c19 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Tue, 23 Jun 2020 20:35:41 +0530 Subject: [PATCH 12/34] Update README.md --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index ebe7e8f..7237dc1 100644 --- a/README.md +++ b/README.md @@ -287,7 +287,7 @@ Note: If passed as Array, then ratio of the balance of the senders are preserved ## Compact IndexedDB operations `compactIDB` operations can be used to perform basic IndexedDB operations such as add, read/write, modify and remove.Contains following operations. -#### Important: Compact IndexedDB operations have all been promisified. All output needs to be handled using .then These operations do not return function return values. Once again, they resolve do not return. +#### Important: Compact IndexedDB operations have all been promisified. All output needs to be handled using .then These operations do not return function return values. Once again, they resolve: they do not return. #### setDefaultDB compactIDB.setDefaultDB(dbName) @@ -358,7 +358,7 @@ This module contains functions that interact with the supernode to send and retr ## FLO Cloud API operations `floCloudAPI` operations can interact with floSupernode cloud to send and retrieve data for applications. floCloudAPI uses floSupernode module for backend interactions. -#### Important: FLO Cloud API operations have all been promisified. All output needs to be handled using .then These operations do not return function return values. Once again, they resolve do not return. +#### Important: FLO Cloud API operations have all been promisified. All output needs to be handled using .then These operations do not return function return values. Once again, they resolve: they do not return. #### sendApplicationData floCloudAPI.sendApplicationData(message, type, options = {}) From 863e4f465df904f7fff2039a21af87891a31bbd9 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Tue, 23 Jun 2020 20:36:11 +0530 Subject: [PATCH 13/34] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 7237dc1..7485c5c 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -# Standard_Operations +# FLO Standard Operations RanchiMall is releasing FLO Standard Operations in order to make it easier for everyone in community to access common functions that any developer would need in a standardized way for JavaScript based development around FLO Blockchain ecosystem. The methods enable developers to read and write into FLO Blockchain directly without any wallet or Chrome extension dependencies. They also enable developers to create digital signatures for any message out of any FLO ID, and functions verify them as well. In additional, standard methods are being provided for data encryption using recipient FLO ID and private key splitting using Shamir Secret Sharing algorithm. From b6affaf6eac044f8c825c60ce7d7454d3c299b63 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sun, 5 Jul 2020 10:23:00 +0530 Subject: [PATCH 14/34] Update README.md --- README.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 7485c5c..dfde3c9 100644 --- a/README.md +++ b/README.md @@ -584,13 +584,17 @@ Parameters while sending * `comment` - user comment of the data ##### Important: Never use senderIDs in SEND DATA options. The system automatically picks the FLO ID of the sender from FLO Globals. Its a common mistake developers make. - + +##### Type is mandatory in SEND DATA because without at least one data identifier like TYPE, the message cannot be retrieved back ### REQUEST DATA +Parameters while requesting + + * `Type`: User defined type (retrieves all data of that type which the sender might have used in SEND DATA phase) + #### request options * `receiverID` - receiver FLO ID of the data - * `type` - type of the data ( a free user field that sender might have used in SEND DATA phase) * `senderIDs` - array of senderIDs * `application` - application of the data * `comment` - comment of the data From 01b5c5f490f1b1655a24b2808b38f4ab94aebb85 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sun, 5 Jul 2020 10:26:00 +0530 Subject: [PATCH 15/34] Update README.md --- README.md | 154 +++++++++++++++++++++++++++--------------------------- 1 file changed, 78 insertions(+), 76 deletions(-) diff --git a/README.md b/README.md index dfde3c9..d8ccf1f 100644 --- a/README.md +++ b/README.md @@ -422,80 +422,7 @@ Note: value of objectData is taken from floGlobals * atVectorClock - VC at which the data is to requested * mostRecent - boolean (true: request only the recent data matching the pattern) -## FLO Decentralised Applications (Dapps) -`floDapps` module contains methods for basic Dapp. floDapps uses all of the above modules. - - - -#### setCustomPrivKeyInput - floDapps.setCustomPrivKeyInput(customFn) -`setCustomPrivKeyInput` adds a startup funtion to the Dapp -1. customFn - custom function to get login credentials (privateKey) - - -#### manageSubAdmins - floDapps.manageSubAdmins(adminPrivKey, addList, rmList) -`manageSubAdmins` adds and/or removes subAdmins by sending transaction to blockchain. -1. adminPrivKey - private key of the adminID -2. addList - Array of subAdmins to add -3. rmList - Array of subAdmins to remove - - -* Example: floDapps.manageSubAdmins(adminPrivKey, [addr1, addr2..]) to add addr1 and addr2 as subAdmin -* Example: floDapps.manageSubAdmins(adminPrivKey, null, [addr1, addr2..]) to remove addr1 and addr2 as subAdmin - - -#### clearCredentials - floDapps.clearCredentials() -`clearCredentials` removes the login credentials stored in IDB. - -#### securePrivKey - floDapps.securePrivKey(pwd) -`securePrivKey` replaces the stored private key with an encrypted variant -1. pwd - password for the encryption -Note: if securePrivKey is used, then password must be requested during customPrivKeyInput (in setCustomPrivKeyInput). - -#### getNextGeneralData - floDapps.getNextGeneralData(type, vectorClock, options = {}) -`getNextGeneralData` return the next generaldata -1. type - type of the general data -2. vectorClock - current known VC, from which next data to be retrived -3. options - (optional, {comment, application} of the data) - -#### launchStartUp - floDapps.launchStartUp() -`launchStartUp` launchs the Dapp startup functions - -##### reactorEvents -* startUpSuccessLog - called when a startup funtion is successfully completed -* startUpErrorLog - called when a startup funtion encounters an error - -##### onLoadStartUp -Sample startup is defined in onLoadStartUp function - -#### addStartUpFunction - floDapps.addStartUpFunction(fname, fn) -`addStartUpFunction` adds a startup funtion to the Dapp -1. fname - Name of the startup function -2. fn - body of the function -Note: startup funtions are called in parallel. Therefore only add custom startup funtion only if it can run in parallel with other startup functions. (default startup funtions are read supernode list and subAdmin list from blockchain API, load data from indexedDB, get login credentials) - -### Advanced Dapp functions usually not needed for users - -#### setAppObjectStores - floDapps.setAppObjectStores(appObs) -`setAppObjectStores` adds additionals objectstores for the app -1. appObs - additionals objects for the app - -#### objectDataMapper - floDapps.objectDataMapper(object, path, data) -`objectDataMapper` maps the object and data via path -1. object - object to be mapped -2. path - end path for the data holder -3. data - data to be pushed in map - - -# Repeat of Basic Concepts of RanchiMall Blockchain Cloud for developers +# Basic Concepts of RanchiMall Blockchain Cloud for developers * RanchiMall blockchain cloud is a service to provide a set of decentralized servers that will provide data storage to users. These decentralized servers are listed in the FLO Blockchain under an authorized FLO address. This gives the assurance to the users that those data servers can be trusted. @@ -570,7 +497,7 @@ Note: * `Object Data:` Type field has been consumed to create object functionality -## 4. General Data +## 4. GENERAL DATA ### SEND DATA Parameters while sending @@ -603,7 +530,7 @@ Parameters while requesting * `atVectorClock` - VC at which the data is to requested * `mostRecent` - boolean (true: request only the recent data matching the pattern. Just the last one) -## 5. ObjectData +## 5. OBJECT DATA ### RESET or UPDATE operations Parameters while resetting or updating @@ -649,3 +576,78 @@ Usually ObjectData and GeneralData systems will support most of user needs. But #### No local IDB storage Application Data results are not stored in local IndexedDB by Standard Operations Framework. + +## FLO Decentralised Applications (Dapps) +`floDapps` module contains methods for basic Dapp. floDapps uses all of the above modules. + + + +#### setCustomPrivKeyInput + floDapps.setCustomPrivKeyInput(customFn) +`setCustomPrivKeyInput` adds a startup funtion to the Dapp +1. customFn - custom function to get login credentials (privateKey) + + +#### manageSubAdmins + floDapps.manageSubAdmins(adminPrivKey, addList, rmList) +`manageSubAdmins` adds and/or removes subAdmins by sending transaction to blockchain. +1. adminPrivKey - private key of the adminID +2. addList - Array of subAdmins to add +3. rmList - Array of subAdmins to remove + + +* Example: floDapps.manageSubAdmins(adminPrivKey, [addr1, addr2..]) to add addr1 and addr2 as subAdmin +* Example: floDapps.manageSubAdmins(adminPrivKey, null, [addr1, addr2..]) to remove addr1 and addr2 as subAdmin + + +#### clearCredentials + floDapps.clearCredentials() +`clearCredentials` removes the login credentials stored in IDB. + +#### securePrivKey + floDapps.securePrivKey(pwd) +`securePrivKey` replaces the stored private key with an encrypted variant +1. pwd - password for the encryption +Note: if securePrivKey is used, then password must be requested during customPrivKeyInput (in setCustomPrivKeyInput). + +#### getNextGeneralData + floDapps.getNextGeneralData(type, vectorClock, options = {}) +`getNextGeneralData` return the next generaldata +1. type - type of the general data +2. vectorClock - current known VC, from which next data to be retrived +3. options - (optional, {comment, application} of the data) + +#### launchStartUp + floDapps.launchStartUp() +`launchStartUp` launchs the Dapp startup functions + +##### reactorEvents +* startUpSuccessLog - called when a startup funtion is successfully completed +* startUpErrorLog - called when a startup funtion encounters an error + +##### onLoadStartUp +Sample startup is defined in onLoadStartUp function + +#### addStartUpFunction + floDapps.addStartUpFunction(fname, fn) +`addStartUpFunction` adds a startup funtion to the Dapp +1. fname - Name of the startup function +2. fn - body of the function +Note: startup funtions are called in parallel. Therefore only add custom startup funtion only if it can run in parallel with other startup functions. (default startup funtions are read supernode list and subAdmin list from blockchain API, load data from indexedDB, get login credentials) + +### Advanced Dapp functions usually not needed for users + +#### setAppObjectStores + floDapps.setAppObjectStores(appObs) +`setAppObjectStores` adds additionals objectstores for the app +1. appObs - additionals objects for the app + +#### objectDataMapper + floDapps.objectDataMapper(object, path, data) +`objectDataMapper` maps the object and data via path +1. object - object to be mapped +2. path - end path for the data holder +3. data - data to be pushed in map + + + From 39a09be7d9068ef5bc55296c4c703c2132330293 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sun, 5 Jul 2020 11:16:08 +0530 Subject: [PATCH 16/34] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index d8ccf1f..4806b94 100644 --- a/README.md +++ b/README.md @@ -534,7 +534,7 @@ Parameters while requesting ### RESET or UPDATE operations Parameters while resetting or updating - * `Object Data` + * `Object Name` The object data with Object Name must be defined #### Options * `receiverID` - receiver FLO ID of the data From beebb5795a590a3bd1d403e108349d834a72fc40 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sun, 5 Jul 2020 13:12:16 +0530 Subject: [PATCH 17/34] Update README.md --- README.md | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 4806b94..f4136c4 100644 --- a/README.md +++ b/README.md @@ -367,11 +367,16 @@ This module contains functions that interact with the supernode to send and retr 2. type - type of the data 3. options - (optional, options detailed at end of module) + +Note: type is mandatory while sending but optional while requesting in case of Application Data. This allows ApplicationData to span different types in retrieval. + #### requestApplicationData floCloudAPI.requestApplicationData(options = {}) `requestApplicationData` requests application data from the cloud. 1. options - (optional, options detailed at end of module) +Note: type is mandatory while sending but optional while requesting in case of Application Data. This allows ApplicationData to span different types in retrieval. + #### sendGeneralData floCloudAPI.sendGeneralData(message, type, options = {}) `sendGeneralData` sends general data to the cloud. @@ -390,26 +395,28 @@ This module contains functions that interact with the supernode to send and retr `resetObjectData` resets the objectData to cloud. 1. objectName - Name of the objectData to be reset 2. options - (optional, options detailed at end of module) -Note: value of objectData is taken from floGlobals +Note: value of objectData is taken from floGlobals.appObjects[objectName] #### updateObjectData floCloudAPI.updateObjectData(objectName, options = {}) `updateObjectData` updates the objectData to cloud. 1. objectName - Name of the objectData to be updated 2. options - (optional, options detailed at end of module) -Note: value of objectData is taken from floGlobals +Note: value of objectData is taken from floGlobals.appObjects[objectName] #### requestObjectData floCloudAPI.requestObjectData(objectName, options = {}) `requestObjectData` requests application data from the cloud. 1. objectName - Name of the objectData to be requested 2. options - (optional, options detailed at end of module) +Note: The resolved output is available at floGlobals.appObjects[objectName] #### options: * send options: * receiverID - received of the data * application - application of the data * comment - comment of the data + * request options * receiverID - received of the data From ec0d420ca795a1b823cf40fb7d36a8e655e46916 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sun, 5 Jul 2020 13:36:14 +0530 Subject: [PATCH 18/34] Update README.md --- README.md | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index f4136c4..0994222 100644 --- a/README.md +++ b/README.md @@ -396,6 +396,8 @@ Note: type is mandatory while sending but optional while requesting in case of A 1. objectName - Name of the objectData to be reset 2. options - (optional, options detailed at end of module) Note: value of objectData is taken from floGlobals.appObjects[objectName] +The object data corresponding with Object Name must be defined in floGlobals.appObjects[objectName] before a reset can be done + #### updateObjectData floCloudAPI.updateObjectData(objectName, options = {}) @@ -403,6 +405,8 @@ Note: value of objectData is taken from floGlobals.appObjects[objectName] 1. objectName - Name of the objectData to be updated 2. options - (optional, options detailed at end of module) Note: value of objectData is taken from floGlobals.appObjects[objectName] +The object data corresponding with Object Name must be defined in floGlobals.appObjects[objectName] before an update can be done + #### requestObjectData floCloudAPI.requestObjectData(objectName, options = {}) @@ -517,9 +521,9 @@ Parameters while sending * `application` - application using the data * `comment` - user comment of the data -##### Important: Never use senderIDs in SEND DATA options. The system automatically picks the FLO ID of the sender from FLO Globals. Its a common mistake developers make. +Important: Never use senderIDs in SEND DATA options. The system automatically picks the FLO ID of the sender from FLO Globals. Its a common mistake developers make. -##### Type is mandatory in SEND DATA because without at least one data identifier like TYPE, the message cannot be retrieved back +Type is mandatory in SEND GENERAL DATA because without at least one data identifier like TYPE, the message cannot be retrieved back ### REQUEST DATA @@ -536,18 +540,26 @@ Parameters while requesting * `upperVectorClock` - VC till which the data is to be requested * `atVectorClock` - VC at which the data is to requested * `mostRecent` - boolean (true: request only the recent data matching the pattern. Just the last one) + +The results are available in floGlobals.generalData +Type is mandatory in REQUEST GENERAL DATA. So every TYPE of general data must be requested individually and separately. +If you want to use requests to give results from all types at one go, use Application Data. ## 5. OBJECT DATA ### RESET or UPDATE operations Parameters while resetting or updating - * `Object Name` The object data with Object Name must be defined + * `Object Name`: Name of the object with data populated in floGlobals.appObjects[objectName] + +Note: The object data corresponding with Object Name must be defined in floGlobals.appObjects[objectName] before a reset or update can be done #### Options * `receiverID` - receiver FLO ID of the data * `application` - application using the data * `comment` - comment of the data -##### Important: Never use senderIDs in RESET and UPDATE. The system automatically picks the FLO ID of the sender from FLO Globals. Its a common mistake developers make. + +Note: Never use senderIDs in RESET and UPDATE. The system automatically picks the FLO ID of the sender from FLO Globals. Its a common mistake developers make. +Note: Type field is never used while RESET, UPDATE or REQUEST operations in Object Data. Type field is internally blocked for Object Data. ### REQUEST DATA @@ -561,7 +573,8 @@ Parameters while resetting or updating * `atVectorClock` - VC at which the data is to requested * `mostRecent` - boolean (true: request only the recent data matching the pattern. Just the last one.) -##### Important: Type field is never used while RESET, UPDATE or REQUEST operations in Object Data. Type field is internally blocked for Object Data. +Note: The output is available in floGlobals.appObjects[objectName] +Note: Type field is never used while RESET, UPDATE or REQUEST operations in Object Data. Type field is internally blocked for Object Data. ## 5. Application Data From 4818cc410a7eeb91ca7bf38d9f4452c8af38c8f5 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sun, 5 Jul 2020 13:43:32 +0530 Subject: [PATCH 19/34] Update README.md --- README.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 0994222..d7c4e40 100644 --- a/README.md +++ b/README.md @@ -541,7 +541,10 @@ Parameters while requesting * `atVectorClock` - VC at which the data is to requested * `mostRecent` - boolean (true: request only the recent data matching the pattern. Just the last one) -The results are available in floGlobals.generalData +The results are available in floGlobals.generalData + +floDapps.getNextGeneralData should be used to retrieve the output in the client browser where the retrieval from floGlobals.generalData has been simplified. + Type is mandatory in REQUEST GENERAL DATA. So every TYPE of general data must be requested individually and separately. If you want to use requests to give results from all types at one go, use Application Data. @@ -559,6 +562,7 @@ Note: The object data corresponding with Object Name must be defined in floGloba * `comment` - comment of the data Note: Never use senderIDs in RESET and UPDATE. The system automatically picks the FLO ID of the sender from FLO Globals. Its a common mistake developers make. + Note: Type field is never used while RESET, UPDATE or REQUEST operations in Object Data. Type field is internally blocked for Object Data. ### REQUEST DATA @@ -586,7 +590,7 @@ Even ObjectData was created on top of Application Data. ObjectData is a special #### Vector Clock issues in Application Data Application data supports Vector clock in REQUEST option, but it is not mandatory. Since Application Data system has no mandatory vector clock requirement in REQUEST OPTIONS, it will always give the entire data set stored in the cloud since start if invoked without vectorClock, and user will have to custom handle the request output himself at client end. Our client side framework will not store it for the user. -Usually ObjectData and GeneralData systems will support most of user needs. But for cases when the user wants the entire cloud data set, and no client side framework handling, he should use ApplicationData. Although Application Data system supports lower vectorClock, upper vectorClock, at vectorClock and mostRecentvectorClock as a REQUEST option. +Usually ObjectData and GeneralData systems will support most of user needs. But for cases when the user wants the entire cloud data set, and no client side framework handling, he should use ApplicationData. Although Application Data system supports lower vectorClock, upper vectorClock, at vectorClock and mostRecentvectorClock as a REQUEST option, but the processing of these have to be done by user. Unlike in case of ObjectData and GeneralData, the output of Request Application Data is not available in floGlobals. * If lower vectorClock is specified, it will give all cloud stored application data after that vectorClock. * If upper vectorClock is specified, it will give all cloud stored application data before that vectorClock. From 8a6a4fb1d6352612a5b72626f8d6cdbc9727875f Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sun, 5 Jul 2020 14:06:27 +0530 Subject: [PATCH 20/34] Update README.md --- README.md | 242 +++++++++++++++++++++++++++++------------------------- 1 file changed, 132 insertions(+), 110 deletions(-) diff --git a/README.md b/README.md index d7c4e40..c8ab1cc 100644 --- a/README.md +++ b/README.md @@ -360,23 +360,6 @@ This module contains functions that interact with the supernode to send and retr #### Important: FLO Cloud API operations have all been promisified. All output needs to be handled using .then These operations do not return function return values. Once again, they resolve: they do not return. -#### sendApplicationData - floCloudAPI.sendApplicationData(message, type, options = {}) -`sendApplicationData` sends application data to the cloud. -1. message - data to be sent -2. type - type of the data -3. options - (optional, options detailed at end of module) - - -Note: type is mandatory while sending but optional while requesting in case of Application Data. This allows ApplicationData to span different types in retrieval. - -#### requestApplicationData - floCloudAPI.requestApplicationData(options = {}) -`requestApplicationData` requests application data from the cloud. -1. options - (optional, options detailed at end of module) - -Note: type is mandatory while sending but optional while requesting in case of Application Data. This allows ApplicationData to span different types in retrieval. - #### sendGeneralData floCloudAPI.sendGeneralData(message, type, options = {}) `sendGeneralData` sends general data to the cloud. @@ -398,7 +381,6 @@ Note: type is mandatory while sending but optional while requesting in case of A Note: value of objectData is taken from floGlobals.appObjects[objectName] The object data corresponding with Object Name must be defined in floGlobals.appObjects[objectName] before a reset can be done - #### updateObjectData floCloudAPI.updateObjectData(objectName, options = {}) `updateObjectData` updates the objectData to cloud. @@ -407,31 +389,144 @@ The object data corresponding with Object Name must be defined in floGlobals.app Note: value of objectData is taken from floGlobals.appObjects[objectName] The object data corresponding with Object Name must be defined in floGlobals.appObjects[objectName] before an update can be done - #### requestObjectData floCloudAPI.requestObjectData(objectName, options = {}) `requestObjectData` requests application data from the cloud. 1. objectName - Name of the objectData to be requested 2. options - (optional, options detailed at end of module) -Note: The resolved output is available at floGlobals.appObjects[objectName] +Note: The output is available at floGlobals.appObjects[objectName] after the promise is resolved -#### options: -* send options: - * receiverID - received of the data - * application - application of the data - * comment - comment of the data - +#### sendApplicationData + floCloudAPI.sendApplicationData(message, type, options = {}) +`sendApplicationData` sends application data to the cloud. +1. message - data to be sent +2. type - type of the data +3. options - (optional, options detailed at end of module) + +Note: type is mandatory while sending but optional while requesting in case of Application Data. This allows ApplicationData to span different types in retrieval. + +#### requestApplicationData + floCloudAPI.requestApplicationData(options = {}) +`requestApplicationData` requests application data from the cloud. +1. options - (optional, options detailed at end of module) + +Note: type is mandatory while sending but optional while requesting in case of Application Data. This allows ApplicationData to span different types in retrieval. +Note: Application Data results are not stored in local IndexedDB by Standard Operations Framework. + +## 4. GENERAL DATA PARAMETERS AND OPTIONS + +### SEND DATA +Parameters while sending + + * `Message`: Actual Message to be sent + * `Type`: User defined type (anything that user wants to classify as type) + +#### Options + * `receiverID` - receiver of the data + * `application` - application using the data + * `comment` - user comment of the data + +Important: Never use senderIDs in SEND DATA options. The system automatically picks the FLO ID of the sender from FLO Globals. Its a common mistake developers make. + +Type is mandatory in SEND GENERAL DATA because without at least one data identifier like TYPE, the message cannot be retrieved back + +### REQUEST DATA + +Parameters while requesting + + * `Type`: User defined type (retrieves all data of that type which the sender might have used in SEND DATA phase) + +#### request options + * `receiverID` - receiver FLO ID of the data + * `senderIDs` - array of senderIDs + * `application` - application of the data + * `comment` - comment of the data + * `lowerVectorClock` - VC from which the data is to be requested + * `upperVectorClock` - VC till which the data is to be requested + * `atVectorClock` - VC at which the data is to requested + * `mostRecent` - boolean (true: request only the recent data matching the pattern. Just the last one) + +The results are available in floGlobals.generalData after the request promise has been resolved + +floDapps.getNextGeneralData should be used to retrieve the output in the client browser where the retrieval from floGlobals.generalData has been simplified. + +Type is mandatory in REQUEST GENERAL DATA. So every TYPE of general data must be requested individually and separately. + +If you want to use requests to give results from all types at one go, use Application Data. + +## 5. OBJECT DATA PARAMETERS AND OPTIONS + +### RESET or UPDATE operations +Parameters while resetting or updating + * `Object Name`: Name of the object with data populated in floGlobals.appObjects[objectName] + +Note: The object data corresponding with Object Name must be defined in floGlobals.appObjects[objectName] before a reset or update can be done + +#### Options + * `receiverID` - receiver FLO ID of the data + * `application` - application using the data + * `comment` - comment of the data + +Note: Never use senderIDs in RESET and UPDATE. The system automatically picks the FLO ID of the sender from FLO Globals. Its a common mistake developers make. + +Note: Type field is never used in RESET, UPDATE or REQUEST operations in Object Data. Type field is internally blocked for Object Data. + +### REQUEST DATA + +#### request options + * `receiverID` - receiver FLO ID of the data + * `senderIDs` - array of senderIDs + * `application` - application of the data + * `comment` - comment of the data + * `lowerVectorClock` - VC from which the data is to be requested + * `upperVectorClock` - VC till which the data is to be requested + * `atVectorClock` - VC at which the data is to requested + * `mostRecent` - boolean (true: request only the recent data matching the pattern. Just the last one.) + +Note: The output is available in floGlobals.appObjects[objectName] after request Object Data promise is resolved +Note: Type field is never used while RESET, UPDATE or REQUEST operations in Object Data. Type field is internally blocked for Object Data. + +## 6. APPLICATION DATA PARAMETERS, OPTIONS AND EXPLANATIONS + +### SEND DATA +Parameters while sending + + * `Message`: Actual Message to be sent + * `Type`: User defined type (anything that user wants to classify as type) + +#### Options + * `receiverID` - receiver of the data + * `application` - application using the data + * `comment` - user comment of the data + +Important: Never use senderIDs in SEND DATA options. The system automatically picks the FLO ID of the sender from FLO Globals. Its a common mistake developers make. + +Type is mandatory in SEND APPLICATION DATA because without at least one data identifier like TYPE, the message cannot be retrieved back + +### REQUEST DATA + +#### Mandatory Parameters while requesting +None + +#### request options + * `receiverID` - receiver FLO ID of the data + * `Type`: User defined type (retrieves all data of that type which the sender might have used in SEND DATA phase) + * `senderIDs` - array of senderIDs + * `application` - application of the data + * `comment` - comment of the data + * `lowerVectorClock` - VC from which the data is to be requested + * `upperVectorClock` - VC till which the data is to be requested + * `atVectorClock` - VC at which the data is to requested + * `mostRecent` - boolean (true: request only the recent data matching the pattern. Just the last one) + +Note: Results will be available in promise.resolve(requestApplicationData(..)), and user will have to handle the response himself. + +Note: TYPE is mandatory while SEND APPLICATION DATA but not in REQUEST APPLICATION DATA. This enables a single Application Data request to fetch across all TYPES + +Note: We recommend developers to use either objectData or GeneralData as we provide inbuilt data synchronization with cloud in them. If developer wants to receive response across all TYPES, or he is interested in doing request response management of the promise himself, he should use Application Data. Rad more in next section. + +Note: Application Data results are not stored in local IndexedDB by Standard Operations Framework. -* request options - * receiverID - received of the data - * senderIDs - array of senderIDs - * application - application of the data - * type - type of the data - * comment - comment of the data - * lowerVectorClock - VC from which the data is to be requested - * upperVectorClock - VC till which the data is to be requested - * atVectorClock - VC at which the data is to requested - * mostRecent - boolean (true: request only the recent data matching the pattern) # Basic Concepts of RanchiMall Blockchain Cloud for developers @@ -508,81 +603,8 @@ Note: * `Object Data:` Type field has been consumed to create object functionality -## 4. GENERAL DATA -### SEND DATA -Parameters while sending - - * `Message`: Actual Message to be sent - * `Type`: User defined type (anything that user wants to classify as type) - -#### Options - * `receiverID` - receiver of the data - * `application` - application using the data - * `comment` - user comment of the data - -Important: Never use senderIDs in SEND DATA options. The system automatically picks the FLO ID of the sender from FLO Globals. Its a common mistake developers make. - -Type is mandatory in SEND GENERAL DATA because without at least one data identifier like TYPE, the message cannot be retrieved back - -### REQUEST DATA - -Parameters while requesting - - * `Type`: User defined type (retrieves all data of that type which the sender might have used in SEND DATA phase) - -#### request options - * `receiverID` - receiver FLO ID of the data - * `senderIDs` - array of senderIDs - * `application` - application of the data - * `comment` - comment of the data - * `lowerVectorClock` - VC from which the data is to be requested - * `upperVectorClock` - VC till which the data is to be requested - * `atVectorClock` - VC at which the data is to requested - * `mostRecent` - boolean (true: request only the recent data matching the pattern. Just the last one) - -The results are available in floGlobals.generalData - -floDapps.getNextGeneralData should be used to retrieve the output in the client browser where the retrieval from floGlobals.generalData has been simplified. - -Type is mandatory in REQUEST GENERAL DATA. So every TYPE of general data must be requested individually and separately. -If you want to use requests to give results from all types at one go, use Application Data. - -## 5. OBJECT DATA - -### RESET or UPDATE operations -Parameters while resetting or updating - * `Object Name`: Name of the object with data populated in floGlobals.appObjects[objectName] - -Note: The object data corresponding with Object Name must be defined in floGlobals.appObjects[objectName] before a reset or update can be done - -#### Options - * `receiverID` - receiver FLO ID of the data - * `application` - application using the data - * `comment` - comment of the data - -Note: Never use senderIDs in RESET and UPDATE. The system automatically picks the FLO ID of the sender from FLO Globals. Its a common mistake developers make. - -Note: Type field is never used while RESET, UPDATE or REQUEST operations in Object Data. Type field is internally blocked for Object Data. - -### REQUEST DATA - -#### request options - * `receiverID` - receiver FLO ID of the data - * `senderIDs` - array of senderIDs - * `application` - application of the data - * `comment` - comment of the data - * `lowerVectorClock` - VC from which the data is to be requested - * `upperVectorClock` - VC till which the data is to be requested - * `atVectorClock` - VC at which the data is to requested - * `mostRecent` - boolean (true: request only the recent data matching the pattern. Just the last one.) - -Note: The output is available in floGlobals.appObjects[objectName] -Note: Type field is never used while RESET, UPDATE or REQUEST operations in Object Data. Type field is internally blocked for Object Data. - -## 5. Application Data - -#### Philosophy +#### Philosophy of Application Data Application data system is original data field system that we created for our cloud. It does not integrate with local IDB storage and synchronization in the browser. In our development process, General Data was created by adding vector clock support to application data at browser level to synchronize cloud and local IDB. SEND and REQUEST options in Application Data are exactly the same as General data without vector clock IDB local storage support at browser level. Even ObjectData was created on top of Application Data. ObjectData is a special construction provided by framework so that Javacript objects can directly be stored and retrieved from the cloud From 52161549403f5946e27a1ef4cfc271d5ebaa79dd Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sun, 5 Jul 2020 14:14:39 +0530 Subject: [PATCH 21/34] Update README.md --- README.md | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index c8ab1cc..ab0de4b 100644 --- a/README.md +++ b/README.md @@ -415,7 +415,7 @@ Note: Application Data results are not stored in local IndexedDB by Standard Op ## 4. GENERAL DATA PARAMETERS AND OPTIONS -### SEND DATA +### SEND GENERAL DATA Parameters while sending * `Message`: Actual Message to be sent @@ -430,15 +430,15 @@ Important: Never use senderIDs in SEND DATA options. The system automatically pi Type is mandatory in SEND GENERAL DATA because without at least one data identifier like TYPE, the message cannot be retrieved back -### REQUEST DATA +### REQUEST GENERAL DATA Parameters while requesting * `Type`: User defined type (retrieves all data of that type which the sender might have used in SEND DATA phase) #### request options - * `receiverID` - receiver FLO ID of the data - * `senderIDs` - array of senderIDs + * `receiverID` - receiver FLO ID of the data. ReceiverID is always a single value in our cloud design + * `senderIDs` - array of senderIDs. This must be in an array even if a single senderID is requested * `application` - application of the data * `comment` - comment of the data * `lowerVectorClock` - VC from which the data is to be requested @@ -456,7 +456,7 @@ If you want to use requests to give results from all types at one go, use Applic ## 5. OBJECT DATA PARAMETERS AND OPTIONS -### RESET or UPDATE operations +### RESET or UPDATE OBJECT DATA Parameters while resetting or updating * `Object Name`: Name of the object with data populated in floGlobals.appObjects[objectName] @@ -471,11 +471,14 @@ Note: Never use senderIDs in RESET and UPDATE. The system automatically picks th Note: Type field is never used in RESET, UPDATE or REQUEST operations in Object Data. Type field is internally blocked for Object Data. -### REQUEST DATA +### REQUEST OBJECT DATA + +#### Mandatory +`Object Name` #### request options - * `receiverID` - receiver FLO ID of the data - * `senderIDs` - array of senderIDs + * `receiverID` - receiver FLO ID of the data. ReceiverID is always a single value in our cloud design. + * `senderIDs` - array of senderIDs. This must be in an array even if a single senderID is requested * `application` - application of the data * `comment` - comment of the data * `lowerVectorClock` - VC from which the data is to be requested @@ -488,7 +491,7 @@ Note: Type field is never used while RESET, UPDATE or REQUEST operations in Obje ## 6. APPLICATION DATA PARAMETERS, OPTIONS AND EXPLANATIONS -### SEND DATA +### SEND APPLICATION DATA Parameters while sending * `Message`: Actual Message to be sent @@ -503,7 +506,7 @@ Important: Never use senderIDs in SEND DATA options. The system automatically pi Type is mandatory in SEND APPLICATION DATA because without at least one data identifier like TYPE, the message cannot be retrieved back -### REQUEST DATA +### REQUEST APPLICATION DATA #### Mandatory Parameters while requesting None From 120ebcf036a9f40f1899d7e692cbe2f031c24f9c Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sun, 5 Jul 2020 14:21:28 +0530 Subject: [PATCH 22/34] Update README.md --- README.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index ab0de4b..b49f588 100644 --- a/README.md +++ b/README.md @@ -426,7 +426,7 @@ Parameters while sending * `application` - application using the data * `comment` - user comment of the data -Important: Never use senderIDs in SEND DATA options. The system automatically picks the FLO ID of the sender from FLO Globals. Its a common mistake developers make. +Important: Never use senderIDs in SEND GENERAL DATA options. The system automatically picks the FLO ID of the sender from FLO Globals. Its a common mistake developers make. Type is mandatory in SEND GENERAL DATA because without at least one data identifier like TYPE, the message cannot be retrieved back @@ -463,7 +463,7 @@ Parameters while resetting or updating Note: The object data corresponding with Object Name must be defined in floGlobals.appObjects[objectName] before a reset or update can be done #### Options - * `receiverID` - receiver FLO ID of the data + * `receiverID` - receiver FLO ID of the data. If this is not specified, the admin ID will be taken as receiverID * `application` - application using the data * `comment` - comment of the data @@ -477,7 +477,7 @@ Note: Type field is never used in RESET, UPDATE or REQUEST operations in Object `Object Name` #### request options - * `receiverID` - receiver FLO ID of the data. ReceiverID is always a single value in our cloud design. + * `receiverID` - receiver FLO ID of the data. ReceiverID is always a single value in our cloud design. If this is not specified, the admin ID will be taken as receiverID * `senderIDs` - array of senderIDs. This must be in an array even if a single senderID is requested * `application` - application of the data * `comment` - comment of the data @@ -498,7 +498,7 @@ Parameters while sending * `Type`: User defined type (anything that user wants to classify as type) #### Options - * `receiverID` - receiver of the data + * `receiverID` - receiver of the data. If this is not specified, the admin ID will be taken as receiverID * `application` - application using the data * `comment` - user comment of the data @@ -512,9 +512,9 @@ Type is mandatory in SEND APPLICATION DATA because without at least one data ide None #### request options - * `receiverID` - receiver FLO ID of the data + * `receiverID` - receiver FLO ID of the data. If this is not specified, the admin ID will be taken as receiverID. It is always a single value. * `Type`: User defined type (retrieves all data of that type which the sender might have used in SEND DATA phase) - * `senderIDs` - array of senderIDs + * `senderIDs` - array of senderIDs. This must be in an array even if a single senderID is requested. * `application` - application of the data * `comment` - comment of the data * `lowerVectorClock` - VC from which the data is to be requested @@ -530,6 +530,8 @@ Note: We recommend developers to use either objectData or GeneralData as we prov Note: Application Data results are not stored in local IndexedDB by Standard Operations Framework. +Note: If a blank REQUEST APPLICATION DATA is made, then cloud will give all application data at the admin ID of the application + # Basic Concepts of RanchiMall Blockchain Cloud for developers From 0050648da2ddc8370f2acd43eed4ee038a602d4c Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sun, 5 Jul 2020 14:24:37 +0530 Subject: [PATCH 23/34] Update README.md --- README.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/README.md b/README.md index b49f588..4d67b9e 100644 --- a/README.md +++ b/README.md @@ -411,8 +411,11 @@ Note: type is mandatory while sending but optional while requesting in case of A 1. options - (optional, options detailed at end of module) Note: type is mandatory while sending but optional while requesting in case of Application Data. This allows ApplicationData to span different types in retrieval. + Note: Application Data results are not stored in local IndexedDB by Standard Operations Framework. +Note: If a blank REQUEST APPLICATION DATA is made, then cloud will give all application data at the admin ID of the application + ## 4. GENERAL DATA PARAMETERS AND OPTIONS ### SEND GENERAL DATA From 6c55653f2ad185a9baff624fb0dece6d07be6b65 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sun, 5 Jul 2020 14:26:54 +0530 Subject: [PATCH 24/34] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 4d67b9e..18e70a0 100644 --- a/README.md +++ b/README.md @@ -604,7 +604,7 @@ It allows the clients to retrieve messages before and after a certain time, and * `Object Data`: Message field can only be a JavaScript Object ### System Data Type -* `Application Data`: Application data is the base on which General Data system and Object Data system has been created. The formats for General Data and Application Data are exactly the same. Users will never need to use Application Data. So we have deprecated Application Data. +* `Application Data`: Application data is the base on which General Data system and Object Data system has been created. The formats for General Data and Application Data are exactly the same exfept type is not mandatory in SEND APPLICATION DATA. This should be used if developer wants to do his own response data management, or wants no cloud-client data synchronization. Note: * `General Data:` Type field is mandatory From e065f688afac443391af543826b7072f000aa4bf Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sun, 5 Jul 2020 17:06:15 +0530 Subject: [PATCH 25/34] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 18e70a0..ffab675 100644 --- a/README.md +++ b/README.md @@ -83,7 +83,7 @@ This template contains standard operations that can be used for the following: 7. `SNStorageID`* : SuperNode Storage adminID. 8. `supernodes`⁺ : List of supernodes. 9. `subAdmins`⁺ : subAdmins of the application. -10. `appData`⁺ : Application data for the app (data sent by subAdmins). +10. `appObjects`⁺ : Object Data for the app (data sent by subAdmins). 11. `generalData`⁺: General Data for the app (data sent by any user). 12. `vectorClock`⁺ and `generalVC`⁺ : vectorclocks for application data and general data respectively. From 70f8cd95b1415a71956e5e452038415e82e40072 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sun, 5 Jul 2020 17:15:35 +0530 Subject: [PATCH 26/34] Update README.md --- README.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index ffab675..c8eda3a 100644 --- a/README.md +++ b/README.md @@ -358,7 +358,7 @@ This module contains functions that interact with the supernode to send and retr ## FLO Cloud API operations `floCloudAPI` operations can interact with floSupernode cloud to send and retrieve data for applications. floCloudAPI uses floSupernode module for backend interactions. -#### Important: FLO Cloud API operations have all been promisified. All output needs to be handled using .then These operations do not return function return values. Once again, they resolve: they do not return. +FLO Cloud API operations have all been promisified. All output needs to be handled using .then These operations do not return function return values. Once again, they resolve: they do not return. #### sendGeneralData floCloudAPI.sendGeneralData(message, type, options = {}) @@ -378,7 +378,9 @@ This module contains functions that interact with the supernode to send and retr `resetObjectData` resets the objectData to cloud. 1. objectName - Name of the objectData to be reset 2. options - (optional, options detailed at end of module) + Note: value of objectData is taken from floGlobals.appObjects[objectName] + The object data corresponding with Object Name must be defined in floGlobals.appObjects[objectName] before a reset can be done #### updateObjectData @@ -386,7 +388,9 @@ The object data corresponding with Object Name must be defined in floGlobals.app `updateObjectData` updates the objectData to cloud. 1. objectName - Name of the objectData to be updated 2. options - (optional, options detailed at end of module) + Note: value of objectData is taken from floGlobals.appObjects[objectName] + The object data corresponding with Object Name must be defined in floGlobals.appObjects[objectName] before an update can be done #### requestObjectData @@ -394,6 +398,7 @@ The object data corresponding with Object Name must be defined in floGlobals.app `requestObjectData` requests application data from the cloud. 1. objectName - Name of the objectData to be requested 2. options - (optional, options detailed at end of module) + Note: The output is available at floGlobals.appObjects[objectName] after the promise is resolved #### sendApplicationData From 084aced9b773a1a8f86f1b140e0ab6b687391eaa Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sun, 5 Jul 2020 18:15:34 +0530 Subject: [PATCH 27/34] Update README.md --- README.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/README.md b/README.md index c8eda3a..f4a9a17 100644 --- a/README.md +++ b/README.md @@ -367,6 +367,9 @@ FLO Cloud API operations have all been promisified. All output needs to be handl 2. type - type of the data 3. options - (optional, options detailed at end of module) +Minimal Example: floCloudAPI.sendGeneralData("Hello World", "type1") +Sends "Hello World" message to the cloud with type1 as `type` with `myFloID` as default sender and `floGlobals.adminID` as receiver + #### requestGeneralData floCloudAPI.requestGeneralData(type, options = {}) `requestGeneralData` requests application data from the cloud. @@ -540,6 +543,8 @@ Note: Application Data results are not stored in local IndexedDB by Standard Op Note: If a blank REQUEST APPLICATION DATA is made, then cloud will give all application data at the admin ID of the application +# Examples for FLO Cloud data operations + # Basic Concepts of RanchiMall Blockchain Cloud for developers From f13e87dbf9daaa3e77c20b1de4bb3acb07c8416e Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sun, 5 Jul 2020 18:18:11 +0530 Subject: [PATCH 28/34] Update README.md --- README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index f4a9a17..82f826f 100644 --- a/README.md +++ b/README.md @@ -367,7 +367,8 @@ FLO Cloud API operations have all been promisified. All output needs to be handl 2. type - type of the data 3. options - (optional, options detailed at end of module) -Minimal Example: floCloudAPI.sendGeneralData("Hello World", "type1") +###### Minimal Example: + floCloudAPI.sendGeneralData("Hello World", "type1") Sends "Hello World" message to the cloud with type1 as `type` with `myFloID` as default sender and `floGlobals.adminID` as receiver #### requestGeneralData From 9be2c5103d26f1b4ffdcf66ff149791dfd814c02 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sun, 5 Jul 2020 19:03:29 +0530 Subject: [PATCH 29/34] Update README.md --- README.md | 56 +++++++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 44 insertions(+), 12 deletions(-) diff --git a/README.md b/README.md index 82f826f..bcc5db0 100644 --- a/README.md +++ b/README.md @@ -92,6 +92,12 @@ This template contains standard operations that can be used for the following: 1-8 : Required for all applications. 9-12: Required for applications based on floClouldAPI and floDapps module. +In addition, we have these system variables outside FLO Globals but used globally +1. `myFloID` : FLO ID with which user has logged in +2. `myPubKey` : Public Key attached to the user FLO ID +3. `myPrivKey` : Private Key corresponding to the user FLO ID + + ## FLO Crypto Operations `floCrypto` operations can be used to perform blockchain-cryptography methods. `floCrypto` operations are synchronized and return a value. Contains the following Operations. @@ -369,7 +375,7 @@ FLO Cloud API operations have all been promisified. All output needs to be handl ###### Minimal Example: floCloudAPI.sendGeneralData("Hello World", "type1") -Sends "Hello World" message to the cloud with type1 as `type` with `myFloID` as default sender and `floGlobals.adminID` as receiver +Sends "Hello World" message to the cloud as General Data with type1 as `type` with `myFloID` as default sender and `floGlobals.adminID` as receiver #### requestGeneralData floCloudAPI.requestGeneralData(type, options = {}) @@ -377,33 +383,51 @@ Sends "Hello World" message to the cloud with type1 as `type` with `myFloID` as 1. type - type of the data 2. options - (optional, options detailed at end of module) +###### Minimal Example: + floCloudAPI.requestGeneralData("type1") +Requests all messages of General Data nature from the cloud with type1 as `type` sent by anyone and `floGlobals.adminID` as default receiverID + #### resetObjectData - floCloudAPI.resetObjectData(objectName, options = {}) + floCloudAPI.resetObjectData("objectName", options = {}) `resetObjectData` resets the objectData to cloud. -1. objectName - Name of the objectData to be reset +1. "objectName" - Name of the objectData to be reset. Quotes are must 2. options - (optional, options detailed at end of module) -Note: value of objectData is taken from floGlobals.appObjects[objectName] +Note: value of objectData is taken from floGlobals.appObjects["objectName"] -The object data corresponding with Object Name must be defined in floGlobals.appObjects[objectName] before a reset can be done +The object data corresponding with Object Name must be defined in floGlobals.appObjects["objectName"] before a reset can be done + +###### Minimal Example: + floGlobals.appObjects["myFirstObject"] = {a:1,b:2} + floCloudAPI.resetObjectData("myFirstObject") +Initiates "myFirstObject" with {a:1,b:2}, and sends to cloud with `myFloID` as default sender and `floGlobals.adminID` as receiver #### updateObjectData - floCloudAPI.updateObjectData(objectName, options = {}) + floCloudAPI.updateObjectData("objectName", options = {}) `updateObjectData` updates the objectData to cloud. -1. objectName - Name of the objectData to be updated +1. "objectName" - Name of the objectData to be updated. Quotes are must. 2. options - (optional, options detailed at end of module) -Note: value of objectData is taken from floGlobals.appObjects[objectName] +Note: value of objectData is taken from floGlobals.appObjects["objectName"] -The object data corresponding with Object Name must be defined in floGlobals.appObjects[objectName] before an update can be done +The object data corresponding with Object Name must be defined in floGlobals.appObjects["objectName"] before an update can be done + +###### Minimal Example: + floGlobals.appObjects["myFirstObject"] = {a:1,c:3,d:4} + floCloudAPI.updateObjectData("myFirstObject") +Updates "myFirstObject" with {a:1,c:3,d:4}, and sends to cloud with `myFloID` as default sender and `floGlobals.adminID` as receiver. #### requestObjectData - floCloudAPI.requestObjectData(objectName, options = {}) + floCloudAPI.requestObjectData("objectName", options = {}) `requestObjectData` requests application data from the cloud. -1. objectName - Name of the objectData to be requested +1. "objectName" - Name of the objectData to be requested. Quotes are must. 2. options - (optional, options detailed at end of module) -Note: The output is available at floGlobals.appObjects[objectName] after the promise is resolved +Note: The output is available at floGlobals.appObjects["objectName"] after the promise is resolved + +###### Minimal Example: + floCloudAPI.requestObjectData("myFirstObject") +Requests the latest value of "myFirstObject" from the cloud. The request is sent to cloud with `myFloID` as sender and `floGlobals.adminID` as receiver. The output is available at floGlobals.appObjects["myFirstObject"] #### sendApplicationData floCloudAPI.sendApplicationData(message, type, options = {}) @@ -414,6 +438,10 @@ Note: The output is available at floGlobals.appObjects[objectName] after the pro Note: type is mandatory while sending but optional while requesting in case of Application Data. This allows ApplicationData to span different types in retrieval. +###### Minimal Example: + floCloudAPI.sendGeneralData("Hello Application World", "typeA") +Sends "Hello Application World" message to the cloud as Application Data with typeA as `type` with `myFloID` as default sender and `floGlobals.adminID` as receiver + #### requestApplicationData floCloudAPI.requestApplicationData(options = {}) `requestApplicationData` requests application data from the cloud. @@ -425,6 +453,10 @@ Note: Application Data results are not stored in local IndexedDB by Standard Op Note: If a blank REQUEST APPLICATION DATA is made, then cloud will give all application data at the admin ID of the application +###### Minimal Example: + floCloudAPI.requestApplicationData() +Requests all messages of Apllication Data nature from the cloud with any `type` sent by anyone and `floGlobals.adminID` as receiverID + ## 4. GENERAL DATA PARAMETERS AND OPTIONS ### SEND GENERAL DATA From be52706a05ae585a48a262e770b48633ab2f31cb Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sun, 5 Jul 2020 22:16:52 +0530 Subject: [PATCH 30/34] Update README.md --- README.md | 37 ++++++++++++++++++++++++------------- 1 file changed, 24 insertions(+), 13 deletions(-) diff --git a/README.md b/README.md index bcc5db0..dd80ebf 100644 --- a/README.md +++ b/README.md @@ -467,13 +467,15 @@ Parameters while sending #### Options * `receiverID` - receiver of the data - * `application` - application using the data - * `comment` - user comment of the data + * `application` - name of the application sending the general data + * `comment` - user comment for the data Important: Never use senderIDs in SEND GENERAL DATA options. The system automatically picks the FLO ID of the sender from FLO Globals. Its a common mistake developers make. Type is mandatory in SEND GENERAL DATA because without at least one data identifier like TYPE, the message cannot be retrieved back +Application field is used by the Cloud to judge whether this message should be deleted after 7 days, or stored permanently. Developers should be careful not to change value of application field if the default value enables the message to be stored permanently. Currently messages sent from subadmins for applications notified by the cloud in the FLO Blockchain are stored permanently. So do not change application field as a caution. Use the comment field. + ### REQUEST GENERAL DATA Parameters while requesting @@ -483,8 +485,8 @@ Parameters while requesting #### request options * `receiverID` - receiver FLO ID of the data. ReceiverID is always a single value in our cloud design * `senderIDs` - array of senderIDs. This must be in an array even if a single senderID is requested - * `application` - application of the data - * `comment` - comment of the data + * `application` - name of the application that sent the general data + * `comment` - comments for the data * `lowerVectorClock` - VC from which the data is to be requested * `upperVectorClock` - VC till which the data is to be requested * `atVectorClock` - VC at which the data is to requested @@ -496,7 +498,9 @@ floDapps.getNextGeneralData should be used to retrieve the output in the client Type is mandatory in REQUEST GENERAL DATA. So every TYPE of general data must be requested individually and separately. -If you want to use requests to give results from all types at one go, use Application Data. +If you want to use requests to give results from all types at one go, use Application Data. + +Application field is used by the Cloud to judge whether this message should be deleted after 7 days, or stored permanently. Developers should be careful not to change value of application field if the default value enables the message to be stored permanently. Currently messages sent from subadmins for applications notified by the cloud in the FLO Blockchain are stored permanently. So do not change application field as a caution. Use the comment field. ## 5. OBJECT DATA PARAMETERS AND OPTIONS @@ -508,8 +512,8 @@ Note: The object data corresponding with Object Name must be defined in floGloba #### Options * `receiverID` - receiver FLO ID of the data. If this is not specified, the admin ID will be taken as receiverID - * `application` - application using the data - * `comment` - comment of the data + * `application` - name of the application for sending the object data + * `comment` - comment for the object data Note: Never use senderIDs in RESET and UPDATE. The system automatically picks the FLO ID of the sender from FLO Globals. Its a common mistake developers make. @@ -523,15 +527,18 @@ Note: Type field is never used in RESET, UPDATE or REQUEST operations in Object #### request options * `receiverID` - receiver FLO ID of the data. ReceiverID is always a single value in our cloud design. If this is not specified, the admin ID will be taken as receiverID * `senderIDs` - array of senderIDs. This must be in an array even if a single senderID is requested - * `application` - application of the data - * `comment` - comment of the data + * `application` - name of the application for which the object data is intended + * `comment` - comment for the object data * `lowerVectorClock` - VC from which the data is to be requested * `upperVectorClock` - VC till which the data is to be requested * `atVectorClock` - VC at which the data is to requested * `mostRecent` - boolean (true: request only the recent data matching the pattern. Just the last one.) -Note: The output is available in floGlobals.appObjects[objectName] after request Object Data promise is resolved -Note: Type field is never used while RESET, UPDATE or REQUEST operations in Object Data. Type field is internally blocked for Object Data. +The output is available in floGlobals.appObjects[objectName] after request Object Data promise is resolved + +Type field is never used while RESET, UPDATE or REQUEST operations in Object Data. Type field is internally blocked for Object Data. + +Application field is used by the Cloud to judge whether this message should be deleted after 7 days, or stored permanently. Developers should be careful not to change value of application field if the default value enables the message to be stored permanently. Currently messages sent from subadmins for applications notified by the cloud in the FLO Blockchain are stored permanently. So do not change application field as a caution. Use the comment field. ## 6. APPLICATION DATA PARAMETERS, OPTIONS AND EXPLANATIONS @@ -543,13 +550,15 @@ Parameters while sending #### Options * `receiverID` - receiver of the data. If this is not specified, the admin ID will be taken as receiverID - * `application` - application using the data - * `comment` - user comment of the data + * `application` - name of the application sending the data + * `comment` - user comment for the data Important: Never use senderIDs in SEND DATA options. The system automatically picks the FLO ID of the sender from FLO Globals. Its a common mistake developers make. Type is mandatory in SEND APPLICATION DATA because without at least one data identifier like TYPE, the message cannot be retrieved back +Application field is used by the Cloud to judge whether this message should be deleted after 7 days, or stored permanently. Developers should be careful not to change value of application field if the default value enables the message to be stored permanently. Currently messages sent from subadmins for applications notified by the cloud in the FLO Blockchain are stored permanently. So do not change application field as a caution. Use the comment field. + ### REQUEST APPLICATION DATA #### Mandatory Parameters while requesting @@ -576,6 +585,8 @@ Note: Application Data results are not stored in local IndexedDB by Standard Op Note: If a blank REQUEST APPLICATION DATA is made, then cloud will give all application data at the admin ID of the application +Note: Application field is used by the Cloud to judge whether this message should be deleted after 7 days, or stored permanently. Developers should be careful not to change value of application field if the default value enables the message to be stored permanently. Currently messages sent from subadmins for applications notified by the cloud in the FLO Blockchain are stored permanently. So do not change application field as a caution. Use the comment field. + # Examples for FLO Cloud data operations From 2edf26228a2b902c7d4411332ef7f3512e8fc25f Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sun, 5 Jul 2020 22:26:22 +0530 Subject: [PATCH 31/34] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index dd80ebf..739bb30 100644 --- a/README.md +++ b/README.md @@ -439,7 +439,7 @@ Requests the latest value of "myFirstObject" from the cloud. The request is sent Note: type is mandatory while sending but optional while requesting in case of Application Data. This allows ApplicationData to span different types in retrieval. ###### Minimal Example: - floCloudAPI.sendGeneralData("Hello Application World", "typeA") + floCloudAPI.sendApplicationData("Hello Application World", "typeA") Sends "Hello Application World" message to the cloud as Application Data with typeA as `type` with `myFloID` as default sender and `floGlobals.adminID` as receiver #### requestApplicationData From 9d909ebc8c8a8df6a912f955a8b685e077591de7 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sun, 5 Jul 2020 23:14:32 +0530 Subject: [PATCH 32/34] Update README.md --- README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 739bb30..a3f382f 100644 --- a/README.md +++ b/README.md @@ -474,7 +474,7 @@ Important: Never use senderIDs in SEND GENERAL DATA options. The system automati Type is mandatory in SEND GENERAL DATA because without at least one data identifier like TYPE, the message cannot be retrieved back -Application field is used by the Cloud to judge whether this message should be deleted after 7 days, or stored permanently. Developers should be careful not to change value of application field if the default value enables the message to be stored permanently. Currently messages sent from subadmins for applications notified by the cloud in the FLO Blockchain are stored permanently. So do not change application field as a caution. Use the comment field. +Application field is used by the Cloud to judge whether this message should be deleted after 7 days, or stored permanently. Developers should be careful not to change value of application field if the default value enables the message to be stored permanently. Currently messages sent from subadmins to any receiverID for applications notified by the cloud in the FLO Blockchain are stored permanently. So do not change application field as a caution. Use the comment field. ### REQUEST GENERAL DATA @@ -500,7 +500,7 @@ Type is mandatory in REQUEST GENERAL DATA. So every TYPE of general data must be If you want to use requests to give results from all types at one go, use Application Data. -Application field is used by the Cloud to judge whether this message should be deleted after 7 days, or stored permanently. Developers should be careful not to change value of application field if the default value enables the message to be stored permanently. Currently messages sent from subadmins for applications notified by the cloud in the FLO Blockchain are stored permanently. So do not change application field as a caution. Use the comment field. +Application field is used by the Cloud to judge whether this message should be deleted after 7 days, or stored permanently. Developers should be careful not to change value of application field if the default value enables the message to be stored permanently. Currently messages sent from subadmins to any receiverID for applications notified by the cloud in the FLO Blockchain are stored permanently. So do not change application field as a caution. Use the comment field. ## 5. OBJECT DATA PARAMETERS AND OPTIONS @@ -538,7 +538,7 @@ The output is available in floGlobals.appObjects[objectName] after request Objec Type field is never used while RESET, UPDATE or REQUEST operations in Object Data. Type field is internally blocked for Object Data. -Application field is used by the Cloud to judge whether this message should be deleted after 7 days, or stored permanently. Developers should be careful not to change value of application field if the default value enables the message to be stored permanently. Currently messages sent from subadmins for applications notified by the cloud in the FLO Blockchain are stored permanently. So do not change application field as a caution. Use the comment field. +Application field is used by the Cloud to judge whether this message should be deleted after 7 days, or stored permanently. Developers should be careful not to change value of application field if the default value enables the message to be stored permanently. Currently messages sent from subadmins to any receiverID for applications notified by the cloud in the FLO Blockchain are stored permanently. So do not change application field as a caution. Use the comment field. ## 6. APPLICATION DATA PARAMETERS, OPTIONS AND EXPLANATIONS @@ -585,7 +585,7 @@ Note: Application Data results are not stored in local IndexedDB by Standard Op Note: If a blank REQUEST APPLICATION DATA is made, then cloud will give all application data at the admin ID of the application -Note: Application field is used by the Cloud to judge whether this message should be deleted after 7 days, or stored permanently. Developers should be careful not to change value of application field if the default value enables the message to be stored permanently. Currently messages sent from subadmins for applications notified by the cloud in the FLO Blockchain are stored permanently. So do not change application field as a caution. Use the comment field. +Note: Application field is used by the Cloud to judge whether this message should be deleted after 7 days, or stored permanently. Developers should be careful not to change value of application field if the default value enables the message to be stored permanently. Currently messages sent from subadmins to any receiverID for applications notified by the cloud in the FLO Blockchain are stored permanently. So do not change application field as a caution. Use the comment field. # Examples for FLO Cloud data operations From e2d9adde071403a7d46ff7a03c9fb74c29393922 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sun, 5 Jul 2020 23:16:52 +0530 Subject: [PATCH 33/34] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index a3f382f..f52ad00 100644 --- a/README.md +++ b/README.md @@ -557,7 +557,7 @@ Important: Never use senderIDs in SEND DATA options. The system automatically pi Type is mandatory in SEND APPLICATION DATA because without at least one data identifier like TYPE, the message cannot be retrieved back -Application field is used by the Cloud to judge whether this message should be deleted after 7 days, or stored permanently. Developers should be careful not to change value of application field if the default value enables the message to be stored permanently. Currently messages sent from subadmins for applications notified by the cloud in the FLO Blockchain are stored permanently. So do not change application field as a caution. Use the comment field. +Application field is used by the Cloud to judge whether this message should be deleted after 7 days, or stored permanently. Developers should be careful not to change value of application field if the default value enables the message to be stored permanently. Currently messages sent from subadmins to any receiverID for applications notified by the cloud in the FLO Blockchain are stored permanently. So do not change application field as a caution. Use the comment field. ### REQUEST APPLICATION DATA From 5b93464f420f95865747e3c11fd737133582c4d9 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Wed, 5 Aug 2020 13:49:07 +0530 Subject: [PATCH 34/34] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index f52ad00..634a1b9 100644 --- a/README.md +++ b/README.md @@ -706,7 +706,7 @@ Application Data results are not stored in local IndexedDB by Standard Operatio * Example: floDapps.manageSubAdmins(adminPrivKey, [addr1, addr2..]) to add addr1 and addr2 as subAdmin * Example: floDapps.manageSubAdmins(adminPrivKey, null, [addr1, addr2..]) to remove addr1 and addr2 as subAdmin - +* This command must be run from the console of app page only. #### clearCredentials floDapps.clearCredentials()