Move xml-rpc serialisation/deserialisation into its own module

[timoxley]

The xml-rpc 'protocol' (specifically the serialising and deserializing component) could be easily refactored out of this module and into its own separate module.

Benefits:

• API changes such as those discussed in [Feedback wanted] Move method call events under single event: 'methodCall' #57 could be implemented as new modules, preventing backwards incompatibility for this module.
• More conformant with the single responsibility principle. This module provides the rpc api. The other module provides the implementation specific to xml-rpc.
• Allows sharing of xml-rpc logic with other systems, without having to reinvent/copy-paste code.

Thoughts?

[baalexander]

Lame, I deleted my comment when trying to edit. In summary, the comment was:

• I like the idea
• What's your thoughts on a module name? Currently thinking XmlRpcMarshaller
• What's your thoughts on the API? Similar to the exposed functions now? (serializeMethodCall, deserializeMethodResponse, etc.)
• I'm wondering what it'd take to make the marshaller browser compatible

[timoxley]

I was thinking something along the lines of xmlrpc-protocol, simply because the original idea for the separation was inspired by https://github.com/substack/dnode-protocol#readme.

Ideally, you'd provide a streaming interface and a simple "string in, data structure out" function (and its inverse)

Browser compatibility shouldn't be too much of an issue since the browser has an xml parser already, though it's not streaming. perhaps a browserified sax.

There's a lot to learn from how dnode is set up in regard to structure and and also streaming.

edit: 'Marshaller' is fine, I don't feel strongly about either really. I always imagine a person giving out sheriff badges whenever I imagine a 'marshaller'.

[MiniGod]

I really +1 this. I forked this repo and completely changed the communication layer (tcp instead of http). Basically, the only code that is left from this repo is the serializer and deserializer. For this, it would make a lot of sense to have those in its own module.

[piranna]

+1, I was thinking about split myself the files on a new package so I can use them on my rpc-builder project :-)

[piranna]

Ideally, it would be a module that just export two funcions, pack that accept an object and return a string, and unpack that accept an string and return an object.

About the name, what about XmlrpcPacker? :-)