Machine friendly RPC commands

[tomasbrod]

I think we should start making the RPC calls more machine friendly. Right now some of them are meant for human reading.
Also the commands intended for general use should be documented.

[Lenni]

What should a machine friendly RPC Command look like? I personally think that the commands are fine, even if you call them from other programs.

[denravonska]

The JSON data should be translatable to object properties. For example, "magnitude": 4.0 translates to object.magnitude = 4.0 while "Whitelisted Project Count": 24 does not. Or maybe it depends on the language but we shouldn't rely on that. The API is also inconsistent both in naming conventions and overall data structuring.

[TheCharlatan]

#1065 improves the machine friendliness of the polling rpc.

[RoboticMind]

Is this still an issue after the RPC Overhaul?

[denravonska]

Yeah, the JSON variable names are in many cases written in a human readable form. For example, mymagnitude:

  {
    "CPID": "5a094d7d93f6d6370e78a2ac8c008407",
    "Earliest Payment Time": "08-21-2016 20:50:24",
    "Magnitude (Last Superblock)": 25,
    "Research Payments (14 days)": 97.29000000000002,
    "Daily Paid": 6.949285714285716,
    "Expected Earnings (14 days)": 87.5,
    "Expected Earnings (Daily)": 6.25,
    "Fulfillment %": 111.0109539023277,
    "CPID Lifetime Interest Paid": 1587.077869829997,
    "CPID Lifetime Research Paid": 17295.69999999998,
    "CPID Lifetime Avg Magnitude": 92.30137522820449,
    "CPID Lifetime Payments Per Day": 23.92544494912583,
    "Last Blockhash Paid": "4bc501d41faf7590620d4490e00319b36ed9af8ecc6d887b8846635392c40e0a",
    "Last Block Paid": 1334865,
    "Tx Count": 1583
  },

[iFoggz]

maybe of spacing on the left entry would be more helpful

like "total amount" instead of ("total_amount" and "totalamount")
i see many instances of this practise

[jamescowens]

We really need to look at this from a big picture perspective and make some decisions to stop the brain damage. I am personally in favor of snake case. We have to decide what to do about all of the legacy keys.... changing older rpc JSON key names could break consumers of that data.

We also ought to be thinking about retrofitting Bitcoin's newer RPC code, which has better argument handling, etc. than ours.

[jamescowens]

I am going to put this in Gladys for now.

[div72]

We have to decide what to do about all of the legacy keys.... changing older rpc JSON key names could break consumers of that data.

@cyrossignol @jamescowens Doesn't the RPC changes in #1739 cause this too?

[cyrossignol]

@div72 Yes. I broke backward-compatibility in some manner for most of the Gridcoin-specific RPCs while rewriting Fern. I'm not thrilled about it, but many of these were pretty bad and not worth bloating the code for just to provide strict interoperability. As you know, Fern is a mandatory release, and much of the old data no longer exists or needs to be represented differently. Where the behavior of an RPC changed significantly as well, I switched the response object property names to `snake_case` (this is also my vote going forward). The GridcoinStats explorer and the pools are the public-facing services that depend on Gridcoin-specific RPCs. The operators participate in development discussions and on testnet where these changes to the RPCs run live. We do need to be careful to avoid changing the names for the Bitcoin-related RPC fields. Bitcoin mostly uses `lowercasewithoutspaces`, and Exchanges prefer Bitcoin-compatible RPC interfaces.

…

On 6/17/2020 9:11 AM, div72 wrote: We have to decide what to do about all of the legacy keys.... changing older rpc JSON key names could break consumers of that data. @cyrossignol <https://github.com/cyrossignol> @jamescowens <https://github.com/jamescowens> Doesn't the RPC changes in #1739 <#1739> cause this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#527 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABAVQEH4J6ZTWZOIEEAQFL3RXDFIFANCNFSM4DXSS5HA>.

[jamescowens]

I think @cyrossignol has the right approach. Maintain maximum compatibility with existing baseline bitcoin functionality, but the Gridcoin rpc commands, many of them have (and are now) redone. I like the snake_case names.

[jamescowens]

This will not be complete quite frankly until porting over the Bitcoin RPC code. I am going to deassign the milestone on this for the time being. In general we have adopted the standard of using all lower case and underscores for the parameter names in the JSON output for all new rpc commands.

[iFoggz]

still a lot of work to be done on this and I like snake_case however some changes would have to be known at release so anyone using rpc for data gathering would be able to make the changes.

[jamescowens]

Yes, but remember we are only doing snake_case for Gridcoin specific rpc commands. rpcs that are part of the Bitcoin "api" should follow Bitcoin's standard. there are a few instances where our commands are the same as Bitcoin's but have been extended for Gridcoin functionality. We will have to review those on a case by case basis.

[jamescowens]

In general, this is a second order problem in my book and there are many other more important things to worry about.

[jamescowens]

I am closing this issue. We are doing all new rpc commands in snake_case. The breakage on older commands and trying to get everyone to change is not worth the hassle.