casper-ecosystem / developer-rewards

A place where developers can get rewarded for their contribution to the Casper Ecosystem and Docs
Apache License 2.0
5 stars 1 forks source link

Swift SDK update to node 1.5 - Part 1 #35

Closed tqhuy2018 closed 10 months ago

tqhuy2018 commented 11 months ago

Reward Size in USD

1000 USD

Reward category

SDK

Description

We have developed Swift SDK for Casper node version 1.4 for the following methods:

  1. chain_get_state_root_hash
  2. info_get_peers
  3. info_get_deployment
  4. info_get_status
  5. chain_get_block_transfers
  6. chain_get_block
  7. chain_get_era_info_by_switch_block
  8. status_get_item
  9. state_get_dictionary_item
  10. state_get_balance
  11. state_get_auction_info
  12. account_put_deploy

Because the maximum value of the proposal is $ 1000, I will split up 3 proposals each proposal 1000 $ corresponding to 4 methods. This is part 1:

chain_get_state_root_hash info_get_peers info_get_deployment info_get_status

Acceptance Criteria

Following methods of the API Fully updated to 1.5 CSPR node:

Unit tests

KMCreatesWorlds commented 11 months ago

Dear @tqhuy2018,

Could please let us know, how much time are you planing for the implementation and when could we expect the delivery of Part 1 from the proposal?

Thank you very much for your contribution.

Best regards, Karol

tqhuy2018 commented 11 months ago

Dear @KMCreatesWorlds,

I plan 4 days from the date of approval, I can deliver part 1. I hope to be able to be approved all 3 parts at the same time, so that I can actively arrange time. Total 3 parts about 7-10 days to complete.

Thank you.

Best regards, Huy Tran

tqhuy2018 commented 11 months ago

Dear @KMCreatesWorlds, hope you are doing well.

Do you have any update infor?

Best regards, Huy Tran

KMCreatesWorlds commented 11 months ago

Dear @tqhuy2018,

I'm sorry it took a little longer. What I would also like to know before we green-light the development is if all of the points from the https://github.com/casper-network/casper-node/releases/tag/v1.5.1 release would be addressed during adaptation of the SDK (such as adding additional methods which were not part of v1.4).

There are some changes between the versions, which for example address the info_get_status, where additional fields have been added.

According to the 1.5.1 release there weren't however any changes for: chain_get_state_root_hash info_get_peers info_get_deployment

Therefore if you would be so kind to describe which changes would have to be made to the methods, we would review those and then come back to you with our decision.

Thanks a lot and best regards, Karol

tqhuy2018 commented 10 months ago

Dear @KMCreatesWorlds

There is not enough information in the document at this address https://github.com/casper-network/casper-node/releases/tag/v1.5.1. To have a full investigation on what we have to modify or change to the methods, we have to find more sources or make request for each method again and find what fields are added or dismissed by guessing the result back (base on the JSON information result from the request).

However, the results of the analysis cannot be accurate or will be incomplete because the returned results cannot generally represent the types of data that the methods contain. For example, a result can belong to a data type with 10 types, but when sending data to predict only 3 types of results are received, the other 7 types will not be included in the prediction. (For example, if there is a new data type like CLType that can have many values but the analysis process only receives 3 types of values, the evaluation cannot be complete).

Right now I can only find documentation for the method at this address: http://casper-rpc-docs.s3-website-us-east-1.amazonaws.com/ but it doesn’t provide sufficient information. For example as I can see the “chain_get_block” RPC response it gives me block Any of type “null” - which does not make any sense to me. I can see there is a sample result with specific data below, but as I comment above it can not cover all cases of data type that could happen in the result. So would you please let me know if there is additional document with more specific information for these methods?

I still have old version of the full doc which I copy and make a personal document at this address: https://docs.google.com/document/d/1q5Rqir3hfKpm79B49yET3b05_wdMis9ANpX8oUrhmEY/edit Would you please let me know if the address for this document still exists and where can I find it? And it seems that the detail document for data types such as CLType, StoredValue, EraInfo, EraSummary … has changed that I can not access to. It would be very kind of you to give me back the address of the document for them.

We are having difficulty evaluating changes from version 1.4.15 to version 1.5.3. I suggest $ 3000 for all 12 methods, have a lot of change methods, or not, but when I update SDK, I need to review and test the whole to ensure quality.

Can you help me give specific changes for the 12 methods below when updating from 1.4.15 to 1.5.3?

chain_get_state_root_hash info_get_pers info_get_deployment info_get_status chain_get_block_transfers chain_get_block chain_get_era_info_by_switch_block status_get_item State_Get_dictionary_item State_get_balance State_Get_Auction_Info account_put_deploy

Where can I chat directly with you to accelerate this discussion process?

melpadden commented 10 months ago

We are in the process of introducing systematised standard integration tests across all Casper SDKs. Any change to SDKs that we are supporting must incorporate these changes.

In general we are looking to upgrade the standard of code structure and documentation across our SDKs. We are building a team to do just that. We are also looking to improve discoverability of the Node API. So it doesn't make sense to green light this development until the process for doing so is clear.

NicolasZoellner commented 10 months ago

Due to the recurring process of updating and the ongoing process definition, SDK Update Proposals will no longer be included in the DevReward Program and are not a part of it. Therefore, SDK update proposals are highly likely to be rejected in the future.

Thank you for your patience.