implement a method "kite.methods"

[humanchimp]

This method would return a representation of the signatures for all the methods of a kite:

{
    "square": [ "num", "callback" ],
    "pow": [ { "kwargs": [ "base", "exponent" ] }, "callback" ]
}

We can figure out what color to paint the bikeshed, and also discuss whether we want to also support optional type annotations. The idea is that it's a general faculty for finding out what methods are offered by a kite. On the JS side, we can automatically create method shims for each method so that instead of needing to do, say, kite.tell('getRiffiwobbles') we could more handily call kite.getRiffiwobbles(). Also, for the kite website, we can have a bunch of different kind of kites registered, but the javascript client does not need to know specifics about those kites in order to display UI that will let the user call the remote methods.

We could reflect the type information from the registered methods, and represent that in some way, so that the client could optionally validate the types of arguments it receives before sending the message. The type annotation part seems like a nice-to-have, but I think we do need method itself.

[fatih]

We can do it on the Go side with reflections. However there might some limitations, like getting the full function name for certain situations. Or passed callbacks.

I think we need to decide on the lowest common dominator and create a protocol. This would enable us at least to create more stable API's.

[humanchimp]

Bikeshedding aside for now, the lowest common denominator means:

• JSON encoded for easy interop
• support for method names (as they were registered with .HandleFunc(); reflecting the names of the functions themselves is not important, IMO.)
• support for positional arguments and kwargs
• support for a placeholder for callbacks

Nice to have:

• type annotations

I think that the type annotations can really make this nice, but it's going to mean more work for us. I'd like it if we at least plan a way forward that can support implementing optional type annotations at some point in the future.

[humanchimp]

I'll take the first whack at a concrete protocol:

{
  "square": {
    "signatures": [
      [
        {
          "name": "num",
          "type": "float64"
        },
        {
          "name": "callback",
          "type": "function",
          "signatures": [
            [
              {
                "name": "squaredNum",
                "type": "float64"
              }
            ]
          ]
        }
      ]
    ]
  },
  "pow": {
    "signatures": [
      [
        {
          "name": "options",
          "type": "kwargs",
          "arguments": [
            {
              "name": "base",
              "type": "float64"
            },
            {
              "name": "exponent",
              "type": "float64"
            }
          ]
        },
        {
          "name": "callback",
          "type": "function",
          "signatures": [
            [
              {
                "name": "raisedNum",
                "type": "float64"
              }
            ]
          ]
        }
      ]
    ]
  }
}

[fatih]

There is no support for optional arguments on the Go side. Also I want to get rid of callbacks in the long term, supporting them is not a good thing.

I was thinking of a more simpler way, like (pseudo code, going to be JSON):

square: 
    Desc: "Returns the squared number"
    Input: ["integer"]
    Output: ["integer"]

Pow: 
    Desc: "Pow returns  the base-x exponential of y. x is the first arg, y is the second arg"
    Input: ["integer", "integer"]
    Output: ["integer"]

ping:
   Desc: "Responses with a pong message"
   Input: [ "string" ]
   Output: ["string"]

foo:
   Desc: "Foo is a method that let's you do Bar things"
   Input: [ "array", "int"]
   Output: ["string"]

That can be improved, but I was thinking of a more literal output. We should call it once and get the necessary methods once and build our applications around it.

[humanchimp]

Some feedback:

1. we should use JSON, not YAML.
2. Your proposal does not support "kwargs", which are needed.
3. We need to support callbacks for now, even if there is a plan to remove support at some time in the future. "You go to war with the army you have—not the army you might want or wish to have at at a later time." :)
4. You are listing only type annotations, but we need the names of the parameters more urgently than type annotation support.

[humanchimp]

Also, there is support for optional arguments in go, just not optional positional arguments. Go supports optional "kwargs" implemented as map[string]interface{}. Optional arguments are also supported in other programming languages targeted, notably JavaScript

[fatih]

• map[string]interface{} is actually one single argument. You are mimicking optionals argument with it only, it's useful however in certain situations.
• My syntax was a pseudo code (it's JSON) you can see my previous comment I've said it). We could use Input: [Object] which would be essential the same as Input: [map[string]interface{}]. I think you are calling this kwargs ?
• Why is the name of the parameters important?
• Kite library should be also an high-performance distributed server library (not only a good client side counterpart). JS is flexible due to nature of the language, however not all server side languages are alike this. Keeping the protocol simple would allow us iterate fast and also create stable API's.
• I really don't want to support callbacks. We were already thinking of getting rid of them, not adding support for them :)