This commit modifies InfoResult to remove all of the omitempty tags since
the fields should be present in the marshalled JSON regardless of them
being zero values or not.
This commit modifies the types of the GetMiningInfoResult to better match
their underlying types. While the information was all available and
accurate, it's nicer to treat numeric values as proper types instead of
all float64s.
Also, a new networkhashps field has been added for compatibility with the
reference implementation.
This change overrides the cmd return value of custom registered
methods to always return an unparsableCmd if the marshaling as a
JSON-RPC request succeeded, but the request was an invalid structure
for the custom method.
This commit extends the RegisterCustomCmd function to also accept a reply
parser which will be invoked for replies to the custom command via
ReadResultCmd. This allows replies to custom commands to be returned a
concrete structs instead of map[string]interface{}.
ok @jcvernaleo, @jrick
This commit moves all of the structs which deal with command results and
related functions to a new file named jsonresults.go.
This is in preparation of allowing custom results to be registered.
ok @jcvernaleo
This commit marks the CreateMessage and CreateMessageWithId functions as
deprecated as they are no longer maintained due to the new concrete
command approach.
It also updates the package documentation to show the new preferred method
as well as add details about btcd.
ok @jcvernaleo
The existing RpcCommand and TlsRpcCommand were build with
CreateMessage(WithID) in mind since they return an already marshalled
command. The approach was changed to use concrete commands created via
the New<command>Cmd family of functions. However, this means the caller
had to manually marshal the command before calling (Tls)RpcCommand which
was not very user friendly.
This commit adds two new functions named RpcSend and TlsRpcSend which
directly accepts a btcjson.Cmd and handles the marshalling itself.
ok @jcvernaleo
This is no longer required since the RawCmd params now consist of a slice
of raw JSON messages which the registered parser can directly unmarshal.
ok @jcvernaleo
This commit modifies the RawCmd type to use a slice of json.RawMessages so
that unmarshalling each individual parameter can be deferred to the
handler for the command.
This is superior to the old method of using a []interface{} because it
means that each parameter is now unmarshalled into the expected concrete
type directly instead of whatever it happens to be in the JSON. Due to
this, the old behavior where every number was unmarshlled as a float64 and
converted to the appropriate final type, which could lead to odd behavior
when going through marshal/unmarshal cycles, has been eliminated. This
change also means each individual parameter can now be full blown structs
(JSON objects) that marshal and unmarshal themselves which greatly
simplifies complex parameters and removes the need for additional and
error prone code.
This commit contains a lot of changes because every command needed its
MarshalJSON and UnmarshalJSON methods updated to support the new
mechanism. As a part of changing these functions, a new common creation
function for the the RawCmd struct was added to avoid the previous
duplication of the common fields. Also, rather than repeating the method
string in each MarshJSON functon, it makes use of cmd.Method().
Finally, some of the error messages were incorrect and have been corrected
as well as made consistent.
ok @jcvernaleo, @jrick, @owainga
The getwork command alters the output depending on whether or not the
optional data parameter was specified. It is a JSON object when no data
was provided, and a boolean indicating whether a solution was found
when data was provided.
The getwork RPC now only accepts a single optional parameter which, if
present, is a string containing the hex-encoded block data to solve.
Also update the tests for the new correct parameters.
ok @jcvernaleo
