Loading ...
Sorry, an error occurred while loading the content.

1.1WD suggestions update

Expand Messages
  • r.koebler
    hi, I now updated my 1.1WD suggestion/specification. I especially added kwparams and multicall. see: http://84.16.237.14/jsonrpc/ Any comments are greatly
    Message 1 of 8 , May 2, 2007
    • 0 Attachment
      hi,

      I now updated my 1.1WD suggestion/specification.
      I especially added "kwparams" and multicall. see:

      http://84.16.237.14/jsonrpc/

      Any comments are greatly appreciated.

      regards,
      Roland
    • jimcburg
      ... Hi, Roland This is an improvement, IMHO. I m guessing that you are just checking whether people are actually reading the thing, but you have params
      Message 2 of 8 , May 5, 2007
      • 0 Attachment
        --- In json-rpc@yahoogroups.com, "r.koebler" <r.koebler@...> wrote:
        >
        > hi,
        >
        > I now updated my 1.1WD suggestion/specification.
        > I especially added "kwparams" and multicall. see:
        >
        > http://84.16.237.14/jsonrpc/
        >
        > Any comments are greatly appreciated.

        Hi, Roland

        This is an improvement, IMHO.

        I'm guessing that you are just checking whether people are actually
        reading the thing, but you have "params" identified with "by-name" and
        "kwparams" identified with "by-position".

        I, for one, certainly appreciate the addition of kwparams.

        Presuming that "Extensions" are optional, I think you have something
        eminently implementable here.

        From the "sound of chirping crickets," I think there is not much to
        dislike in your suggested JSON-RPC 1.1 .

        Unless nobody is paying attention at all anymore.

        Overall, except a few minor edits, I give your recommendation a +1.

        -Jim Washington
      • Matthew Morley
        Got a vote from me also! I appreciate the efforts, this as a good step forward from the 1.0 spec. -- Matthew P. C. Morley
        Message 3 of 8 , May 6, 2007
        • 0 Attachment
          Got a vote from me also!

          I appreciate the efforts, this as a good step forward from the 1.0 spec.

          --
          Matthew P. C. Morley
        • r.koebler@yahoo.de
          ... oh, thanks. it s corrected now. ... yes, they are optional. ... thanks :). regards, Roland
          Message 4 of 8 , May 6, 2007
          • 0 Attachment
            On Sun, May 06, 2007 at 03:30:53AM -0000, jimcburg wrote:
            > I'm guessing that you are just checking whether people are actually
            > reading the thing, but you have "params" identified with "by-name" and
            > "kwparams" identified with "by-position".
            oh, thanks. it's corrected now.

            > Presuming that "Extensions" are optional,
            yes, they are optional.

            > Overall, except a few minor edits, I give your recommendation a +1.
            thanks :).

            regards,
            Roland
          • Jeffrey Damick
            So the only bad thing is that by adding kwparams and removing the named arguments capability from params is that it is a pretty big change if you ve already
            Message 5 of 8 , May 7, 2007
            • 0 Attachment
              So the only bad thing is that by adding kwparams and removing the named arguments capability from params is that it is a pretty big change if you've already implemented 1.1WD and have it running in several environments (like me)..  This type of divergence from 1.1WD would prevent me (and probably others) from adopting it.  While i see the point about kwparams being more explicit than params, i think { vs. [ is just as easy to visually identify.  Maybe kwparams could only apply if you trying to mix them..


              -jeff


              On 5/6/07, r.koebler@... <r.koebler@... > wrote:

              On Sun, May 06, 2007 at 03:30:53AM -0000, jimcburg wrote:
              > I'm guessing that you are just checking whether people are actually
              > reading the thing, but you have "params" identified with "by-name" and
              > "kwparams" identified with "by-position".
              oh, thanks. it's corrected now.

              > Presuming that "Extensions" are optional,
              yes, they are optional.

              > Overall, except a few minor edits, I give your recommendation a +1.
              thanks :).

              regards,
              Roland


            • Stephen M. McKamey
              I also have JSON-RPC 1.1 working and it works great. kwparams would be a breaking change (not to mention I think kwparams is an inelegant identifier that
              Message 6 of 8 , May 7, 2007
              • 0 Attachment
                I also have JSON-RPC 1.1 working and it works great. kwparams would
                be a breaking change (not to mention I think "kwparams" is an
                inelegant identifier that doesn't fit with the rest).

                I agree with Jeffrey: having just the one params object
                differentiated by type { vs [ would make more sense for me. I never
                understood the need for mixing them anyway. It seems like an
                unneccessary complication to accommodate a very wierd usage.

                --- In json-rpc@yahoogroups.com, "Jeffrey Damick" <jeffreydamick@...>
                wrote:
                >
                > So the only bad thing is that by adding kwparams and removing the
                named
                > arguments capability from params is that it is a pretty big change
                if you've
                > already implemented 1.1WD and have it running in several
                environments (like
                > me).. This type of divergence from 1.1WD would prevent me (and
                probably
                > others) from adopting it. While i see the point about kwparams
                being more
                > explicit than params, i think { vs. [ is just as easy to visually
                identify.
                > Maybe kwparams could only apply if you trying to mix them..
                >
                >
                > -jeff
              • r.koebler@yahoo.de
                ... if you know a better name: tell me. ... ok. but this would mean that you cannot mix named and positional parameters. that would be ok for me, and I already
                Message 7 of 8 , May 7, 2007
                • 0 Attachment
                  On Mon, May 07, 2007 at 03:46:59PM -0000, Stephen M. McKamey wrote:
                  > (not to mention I think "kwparams" is an
                  > inelegant identifier that doesn't fit with the rest).
                  if you know a better name: tell me.

                  > I agree with Jeffrey: having just the one params object
                  > differentiated by type { vs [ would make more sense for me.
                  ok. but this would mean that you cannot mix named and positional
                  parameters. that would be ok for me, and I already suggested that
                  some time ago -- but since some people said they need this mixing,
                  I added kwparams...

                  > understood the need for mixing them anyway. It seems like an
                  > unneccessary complication to accommodate a very wierd usage.
                  here are some examples of RPC-calls with and without mixing:
                  (in python-syntax)

                  - with mixing:
                  sum(23,42)
                  sum(23,42, debug=False)
                  echo("test", times=10)

                  - without mixing, these would look like:
                  sum(23,42)
                  sum(23,42, False)
                  sum(s1=23, s2=42, debug=False)
                  echo("test", 10)
                  echo(content="test", times=10)

                  this i.e. means, that if you use parameters by-position, and want to add
                  a named parameter, you have to completely switch to named parameters.


                  so, if we don't need the "with-mixing"-sytax, we could again
                  drop kwparams, and always use params as array or object.
                  (but there **won't be mixed-parameters in params** like in 1.1WD!)

                  I created a poll for this.

                  regards,
                  Roland
                • Mikeal Rogers
                  Welcome to the world of implementing draft specifications :) It s a risk you take. In my opinion nobody should worry about breaking draft implementations
                  Message 8 of 8 , May 9, 2007
                  • 0 Attachment
                    Welcome to the world of implementing draft specifications :)

                    It's a risk you take. In my opinion nobody should worry about breaking draft implementations during the revision process, the purpose of the revision process is to try and make the standards more interoperable and reduce the barrier for _new_ implementors. It would be a huge burden to try and maintain compatibility between drafts.

                    -Mikeal

                    On May 7, 2007, at 6:26 AM, Jeffrey Damick wrote:

                    So the only bad thing is that by adding kwparams and removing the named arguments capability from params is that it is a pretty big change if you've already implemented 1.1WD and have it running in several environments (like me)..  This type of divergence from 1.1WD would prevent me (and probably others) from adopting it.  While i see the point about kwparams being more explicit than params, i think { vs. [ is just as easy to visually identify.  Maybe kwparams could only apply if you trying to mix them..


                    W



                  Your message has been successfully submitted and would be delivered to recipients shortly.