Feature request: support for JSON in message data

jamtodayjamtoday San FranciscoMember Posts: 13
It would likely be possible for contracts to implement JSON parsing support for message data if it is not a built-in feature, but it would fantastic for contract developers if this just worked off-the-shelf.

Instead of a data being a flat array like ['foobar',123], You can pass in JSON like [{"foo":"bar"},{"nested":{1:{23}}}]. Then from serpent code, you would access the values as you would a Python dictionary:

msg.data[1]["nested"][1] # returns 23 given the JSON example above

Of course, there are likely some limitations I am not aware of but as a contract developer this would be wonderful to have available. It would make it very trivial to bring in JSON-based data from external APIs, and the ability to have several levels of nesting within the data as opposed to a flat array will be helpful once contracts get sufficiently complex and require many pieces of data input.


  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    Well, afaik, it does make transactions weigh more, and thus cost more. And it probably doesnt fit the bill for creating standards entirely either, so of limited use i reckon, probably better to do it all 'compile time'.

    Doing it compile-time might work better. Essentially you just declare..
    contract(...contract parameters...):
    ...init code...

    ...body using arguments...:
  • grapagrapa Member Posts: 10
    Will the code within a contract be able to generate an HTTP POST request to an external web service? Will it be able to digest the response?
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    @grapa, most definitely not. Every full node executes all the code and holds all the data.(but computers are fast, can contain a lot of data, and contracts are comparitively small) So they'd all either have to do the HTTP request or agree on its result otherwise. What if some dont have access to that address.

    However, if you have a client you trust or maybe a combination of them you can create a data feed. Essentially you'd have a computer run somewhere which does the HTTP request, and it turns it into a transaction talking to the contract. Do note that HTTP is very insecure!
Sign In or Register to comment.