HTTP keepalive would be nice.

So, I've been playing with a Counterparty json-rpc server (for reference, don't look too hard at it: http://counterpartyd.readthedocs.org/en/latest/API.html) and it returned me an error everytime I tried to make a request with params saying the following:

{ "message": "Invalid Request", "data": "Arguments must be passed as a JSON object (list of unnamed arguments not supported)" }

I digged deeper into your code and found the issue here:

module Jimson
  class ClientHelper

    def send_single_request(method, args)
      namespaced_method = @namespace.nil? ? method : "#@namespace#{method}"
      post_data = MultiJson.encode({
        'jsonrpc' => JSON_RPC_VERSION,
        'method'  => namespaced_method,
        'params'  => args.try(:first), # <= PROBLEM WAS HERE: it was just `args`
        'id'      => self.class.make_id
      })
      resp = RestClient.post(@url, post_data, @opts)
      if resp.nil? || resp.body.nil? || resp.body.empty?
        raise Client::Error::InvalidResponse.new
      end

      return resp.body
    end

  end

end

So it seems the server I'm interacting with expects params to be a json object and not an array. The fix I applied - using the first element of the array - works, however I'm not sure whether this is something specific to the Counterparty RPC server or maybe it's jimson implementation deficiency. Please take a look at it, you might want to decide to give users more freedom as to how to pass params.

Today, I cannot use a module as a handler:

module MyModule
  extend Jimson::Handler
  def sum(a, b)
    a + b
  end
end

server = Jimson::Server.new(MyHandler)

The reason this fails is because the server expects the class of the object given to respond to a jimson method:

https://github.com/chriskite/jimson/blob/next/lib/jimson/server.rb#L168

A possible approach to this problem is to move this method to the instance, probably something along the lines of jimson_respond_to?. We could use the extended hook to inject this method in the instance.

If agreed, I can work on a pull request. :)

It would be nice for debugging purposes if you would show the response received for Client::InvalidResponse just as you do for InvalidJson

I would like to discuss the possibility to built in jimson some kind of namespace support as a convenience on top of JSON-RPC. This proposal could be implemented in two ways:

Using methods

When the a request comes and the method is "foo.bar", we would invoke "foo" on the handler object that would return another object which "bar" would be called on. However, this approach could lead to security vulnerabilities (for example, given a function returns an array, one could call methods on the Array like pack/unpack that could be CPU or SPACE intensive).

Explicit exposure

A better approach is to whitelist which methods allow nesting, this could be in the Handler API. A proposal is the jimson_nesting method:

extend Jimson::Handler
jimson_namespace :service1

My case

My case is that I want to expose several services via JSON-RPC without actually having to create many ports. For example:

module Handle
  extend Jimson::Handler
  def service1; Service1; end
  def service2; Service2; end
end

And then I would like to invoke it as: "service1.foo".

Client

Today, the client uses method missing and this approach doesn't work with namespace. One option is to allow namespace in the client:

service1 = client.namespace(:service1)
service1.foo

This would be a very thin wrapper around the client that would basically convert the method to "service1.foo".

What do you think? In case you are interested in something like this, please let me know and I will gladly implement it. :)

client.method({'bar' => 'baz'}) will set params to [{'bar' => 'baz']] instead of {'bar' => 'baz'}

Jimson should send back only errors from Jimson::Server::Error or inherited ones. Now it can send errors like NoMethodError.

If you like it, I'll contribute this feature.

Bitcoind does not send "jsonrpc" header back, so without patching jimson it's not possible to use the Jimson client.

Hi,

jimson depends on rest-client ~> 1 and the latest from this lineage is 1.8.0.
rest-client 1.8.0 is not compatible with ruby 2.5 because of upgraded openssl interface.
"key not found: :ciphers"
rest-client-1.8.0/lib/restclient/request.rb:163:in `fetch'

I don't think that rest-client 1.8.1 will be released, so, do you have any plans to move to newer rest-client , say ~> 2 ?

Thanks.

Is there any way to call methods like "user.login"?

Hi,

At present, Jimson depends on:

"rack", "~> 1", ">= 1.4.5"

and is thus unusable in a rails 5 app because ActionPack 5.0.0rc1 depends on:

'rack', '~> 2.x'

Thanks for this great library! Is it possible to get more complex objects across the wire instead of primitives?

Would it be possible to rev the multi_json dependency to ~> 1.7.0 from 1.1.0?