XML-RPC Support about spooky

[Yortw]

Hi,

I confess this is something I'd originally planned to do, but I have no personal use for it and as my OSS projects are all unpaid I tend to spend time on things that are actually useful to me in the short term. I also have to be honest and say that while I designed Spooky to work for multiple RPC protocols (specifically looking at the XML-RPC protocol at the time), I haven't attempted the implementation and cannot be sure I got the interfaces etc. 100% correct. It might be more difficult than I'd intended.

If you have a use for it, I might be able to spend some time looking at it. However I don't have an XML-RPC server to test with or any reason to build one, and my time is limited so may need some assistance with testing etc. and can't give any guarantees it will happen or about the timeframe.

I'd be happy to accept/merge/work on a good PR if you wanted to try yourself.

[mdkozlowski]

I want to write a program that automates interfacing between an rTorrent client instance and an Aria2 client - Aria2 supports JSON-RPC but rTorrent is pretty dated and only exposes an XML-RPC gateway. Python has a lot better support for XML-RPC so I've been honestly considering writing a wrapper in python that exposes all the rTorrent functions I need as REST endpoints, but that's kinda a last resort

I'd be happy to try my own hand at looking over the codebase and implementing XML-RPC in spooky, sometime in December/January. In the meantime if you're interested I can link a docker image that sets up an rTorrent instance with the XML-RPC endpoint configured properly so it's easy to test against

[Yortw]

Is there a minimum version of .Net Standard you need supported?

[mdkozlowski]

I'd like to use it in an ASP.NET Core 2 site so if I'm not mistaken that's .NET Standard 2

[Yortw]

Hi,

I've made a start and it doesn't seem like it should be too hard. However, XML-RPC is a pretty ugly protocol in many respects and it has a different feature set to the json equivalent which leads to some interesting questions. As a potential consumer of the library, would you mind offering some opinions?

I'm using the XML-RPC spec described here; http://xmlrpc.scripting.com/spec.html

• XML-RPC doesn't appear to support 'named parameters', only positional/ordinal ones, unlike the json protocol. Does this mean passing a dictionary/IEnumerable<KeyValuePair<K, V>> as an argument should be an exception? Or should we convert these into a custom 'struct' as described by the spec? Given dictionaries don't really have an order (or use the key sort order) it wouldn't make sense to support them directly as a positional parameter source.

• Dates don't allow time-zone info. If we are passed a DateTimeOffset should we send local time, utc time, or throw an exception?

• There are a limited number of data types for arguments. Numbers are a particular problem since they're limited to 4 byte integers or doubles. If we get a byte/int16 we can probably send it as an i4 parameter, and I guess a single/float can be sent as a double. However what about a long? That could potentially overflow an i4 and so I think it should be an exception, but now you just can't send large integers via the protocol. Also what about 'decimal' values? Seems like it would be bad to convert them to double, but there is no other suitable data type, so again I think this should be an error?

Thanks.

[mdkozlowski]

IMO all 3 of those should raise an exception

Since it literally isn't part of the spec, choosing to go with (basically arbitrarily chosen) default behaviour could cause headaches for users who aren't aware of the specifics. Raising an exception with a link to a wiki page on this repo seems like the best option to me. The wiki page could have an explanation for why the exception is being raised (features unsupported by the spec) and possible remedies (like using a double to store a float) that the user could implement, knowing the context for their application and what the remote server is expecting - as opposed to implementing default behaviour for them

[Yortw]

Thanks. That fits with my thinking generally.
Still trying to decide if the smaller numeric types should be allowed and converted into/out of the larger types in the protocol. I can sort of go either way on whether that's a good idea.

[Yortw]

It's also unclear what to do when calling a method with no args. The language of the spec implies leaving out the params node and all children, but I found this on Stackoverflow which suggests this may be a problem for some servers; https://stackoverflow.com/questions/26626814/xml-rpc-net-server-method-missing-params-with-optional-parameters

[Yortw]

I've got a draft implementation done. I've tested it against a couple of simple XML-RPC services I've found online and it seems to work. The serialisation logic for making the requests is ok, the deserialization logic is inelegant and probably inefficient, but seems good enough for now. I think trying to improve it at this point would be a premature optimisation.

There is a pre-release package on Nuget.

    Install-Package Spooky.Xml -Version 1.0.5-Alpha

[Yortw]

To follow up my previous comment; I haven't done any serious benchmarking, but my unscientific tests of individual XML-RPC calls show performance to be roughly the same as the Json-RPC implementation. Of course this is being done to different servers, but I think the time spent in the Spooky libraries is dwarfed by the network calls, so again, premature optimisation to worry about this until someone has a specific issue.

[Yortw]

Hi,

Have you had a chance to try the pre-release package?

Thanks.

[Yortw]

Closed after no response.
Pre-release package with XML-RPC support now published as official package.