spec defaults <value> to <string> about node-xmlrpc HOT 9 CLOSED

Wrote some code to allow type-less value-elements in #37

from node-xmlrpc.

Thanks @hugobuddel for the pull requests and especially the test cases. I should have time this weekend to look it over in more detail and merge it in.

Just curious, was there a program or other language's XML-RPC server sending you the XML without the String type?

from node-xmlrpc.

Your elaborate test suite proved quite valuable. For example, the <fault><value/></fault>-test initially failed when I changed the code. This might have gone unnoticed without the test.

(Related, I noticed that I hadn't reset the charStream properly. As a result, some tests failed because another test left whitespace in charStream. Perhaps there would be a generic way to prevent a parsing from affecting subsequent parsings?)

There might be better ways to support default string-values though. For example, it might be cleaner to have separate deserializeValue and deserializeParam functions somehow. I'll leave it up to you how to procede.

I was implementing a SAMP 1.3 client (a protocol used in astronomy), using TOPCAT as a server. I do not know how TOPCAT (java, open source) constructs the XML. I'll create more test cases if necessary.

OT: Ultimately my goal is to create a browser-app, not a node-app. However, I thought that it might be easier to develop against node.js and port it later. Would node-xmlrpc (that is, the client part) be portable to a browser?

from node-xmlrpc.

To answer my own question: yes, it is portable to a browser. I created a branch that uses the ahr2 module instead of the http module. This works excellent with the pakmanager module to create a browser based XML-RPC client.

from node-xmlrpc.

Wow @hugobuddel, that's an impressive branch.

I originally wanted the XML-RPC module to work on node and the browser, but I found it easier (and cleaner code) to just target node.

I don't think the browser code should be ported to the main repo right now. I'm still iffy on Ender/Pakmanager vs AMD/Require.js and unsure about using a replacement module (ahr2) for such a core module in node (HTTP and HTTPS).

That said, I can link to your fork in the README for a browser compatible version.

Also, it may be worth creating a repo and npm package for turl.js as I could see that being useful for others.

from node-xmlrpc.

It turned out to be much easier than I expected. I agree that the branch should not be merged into the main repo. At least that was not my intent. Perhaps it would be possible to use ahr2 as a fallback when http(s) is not available.

I though about creating a separate module out of my fork by renaming it. E.g. xmlrpcclient or something. That way it is easier to use as a dependency in other modules.

However, I'm just trying to get some work done that requires an XML-RPC client. I didn't plan to actively maintain a complete module :-). For example, I've only tested it in firefox, not even IE yet.

About turl.js: There must be modules that do this already. I didn't check though. It might even be that ahr2 has something like this already.

from node-xmlrpc.

@hugobuddel - I just wanted to let you know I have not forgotten about this value defaulting to string issue and will try to work on it soon.

from node-xmlrpc.

The defaulting value as String code has been merged. Thanks again.

from node-xmlrpc.

Super!

from node-xmlrpc.