a67baf5a4d
Fedora 33 ships the new API so let's do the switch now. But... this would break older Fedoras because they only have the old API, right? We have the following options: 1) Ship xmlrpc compat package to Fedora 33+. This would mean that we delay the API switch till F32 EOL. This would be the most elegant solution, yet it has two issues: a) We will surely not be able to deliver the compat package before F33 Final Freeze. b) It's an extra and annoying work. 2) Downstream patch. No. 3) Use build constraints and have two versions of our code for both different API. I chose solution #3. It has an issue though: %gobuild macro already passes -tags argument to go build. Therefore the following line fails because it's not possible to use -tags more than once: %gobuild -tags kolo_xmlrpc_oldapi ... Therefore I had to come up with manual tinkering with the build constraints in the spec file. This is pretty ugly but I like that: 1) Go code is actually clean, no weird magic is happening there. 2) We can still ship our software to Fedora/RHEL as we used to (no downstream patches) 3) All downstreams can use the upstream spec file directly. Note that this doesn't affect RHEL in any way as it uses vendored libraries.
2.9 KiB
Overview
xmlrpc is an implementation of client side part of XMLRPC protocol in Go language.
Status
This project is in minimal maintenance mode with no further development. Bug fixes are accepted, but it might take some time until they will be merged.
Installation
To install xmlrpc package run go get github.com/kolo/xmlrpc. To use
it in application add "github.com/kolo/xmlrpc" string to import
statement.
Usage
client, _ := xmlrpc.NewClient("https://bugzilla.mozilla.org/xmlrpc.cgi", nil)
result := struct{
Version string `xmlrpc:"version"`
}{}
client.Call("Bugzilla.version", nil, &result)
fmt.Printf("Version: %s\n", result.Version) // Version: 4.2.7+
Second argument of NewClient function is an object that implements http.RoundTripper interface, it can be used to get more control over connection options. By default it initialized by http.DefaultTransport object.
Arguments encoding
xmlrpc package supports encoding of native Go data types to method arguments.
Data types encoding rules:
- int, int8, int16, int32, int64 encoded to int;
- float32, float64 encoded to double;
- bool encoded to boolean;
- string encoded to string;
- time.Time encoded to datetime.iso8601;
- xmlrpc.Base64 encoded to base64;
- slice encoded to array;
Structs encoded to struct by following rules:
- all public field become struct members;
- field name become member name;
- if field has xmlrpc tag, its value become member name.
- for fields tagged with
",omitempty", empty values are omitted;
Server method can accept few arguments, to handle this case there is
special approach to handle slice of empty interfaces ([]interface{}).
Each value of such slice encoded as separate argument.
Result decoding
Result of remote function is decoded to native Go data type.
Data types decoding rules:
- int, i4 decoded to int, int8, int16, int32, int64;
- double decoded to float32, float64;
- boolean decoded to bool;
- string decoded to string;
- array decoded to slice;
- structs decoded following the rules described in previous section;
- datetime.iso8601 decoded as time.Time data type;
- base64 decoded to string.
Implementation details
xmlrpc package contains clientCodec type, that implements rpc.ClientCodec interface of net/rpc package.
xmlrpc package works over HTTP protocol, but some internal functions and data type were made public to make it easier to create another implementation of xmlrpc that works over another protocol. To encode request body there is EncodeMethodCall function. To decode server response Response data type can be used.
Contribution
See project status.
Authors
Dmitry Maksimov (dmtmax@gmail.com)