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

Should we make a move?

Expand Messages
  • konstantin_yegupov
    1.1 spec STILL isn t complete, and is too complex, in my opinion. An we NEED it finished, to make it enterprise-ready and beat the shit out of immeasurably
    Message 1 of 8 , Jun 1, 2007
    • 0 Attachment
      1.1 spec STILL isn't complete, and is too complex, in my opinion.

      An we NEED it finished, to make it enterprise-ready and beat the shit
      out of immeasurably ugly SOAP.

      Being pragmatic and harsh, I'd propose the following changes:

      1. Drop all 1.0 compatibility. No, really. How many people do really
      use JSON-RPC 1.0? Specifically, let's forget "id" element.
      2. Drop requirements on HTTP headers. It's quite enough for each side
      to receive parsable JSON - then we assume transport layer is ok.
      3. Differentiate strictly between "GET/POST" request types. They are
      NOT completely interchangeable and cause confusion. POST should be the
      main method, because it's all about JSON. GET - is alternative way
      (maybe even another spec, JSON-RPC-Lite).
      4. "params" should be of any type. Int, String and Null should be ok.
      Let server decide how to process it.
      5. Add optional "auth" parameter to request, of arbitrary type. For
      those dudes who don't want to deal with HTTP auth and would like to
      use session ID or sumfin else.

      We need to move forward. Such a brilliant chance to improve Web
      Services world shouldn't be missed.
    • Mikeal Rogers
      I m in 100% agreement with 1, the spec not being finished a big problem, who is responsible for editing the spec? who are the stake holders here and can we
      Message 2 of 8 , Jun 5, 2007
      • 0 Attachment
        I'm in 100% agreement with 1, the spec not being finished a big problem, who is responsible for editing the spec? who are the stake holders here and can we divide some of the work up? is there any formal process what so ever for responding to issues publicly?

        I'm in strong disagreement with 2, these headers are absolutely necessary for proper interop with REST based services and without them this standard will never have a chance at making it through the IETF or a comparable standards certification process.

        On point 3, I too think the use of GET should be a separate specification. Breaking the current spec in to two different use cases is draining and adding a lot of unnecessary complexity.

        I don't see the use case for params being any type other than array or object?

        I also don't see the use case for auth in the parameters, auth should be handled at the HTTP layer which has all the protocol support necessary. If they can't "deal" with HTTP auth (who are these people?), then they can add an arbitrary auth parameter to the params list of all the method calls and parse it out before dispatching the remote method, this will end up being more interoperable than having a base level attribute with no specific semantics other than "it might hold auth or session data in some format" and we don't want to add a bunch of extra auth semantics to the current spec.

        I'd like to add one point, get off of yahoo groups. The formatting of these emails make responses difficult when the html bodies barely parse. Not to mention the annoying ads that are added to each email. My participation has been lessened by the fact that using yahoo groups is painful. I can suggest various alternatives and may even be able to get IT here at the Open Source Applications Foundation to set up a mailman account for the json-rpc community, we already host an IETF working group and some other open standards/projects group lists that aren't directly funded by OSAF.

        -Mikeal

        On Jun 1, 2007, at 5:22 AM, konstantin_yegupov wrote:

        1.1 spec STILL isn't complete, and is too complex, in my opinion.

        An we NEED it finished, to make it enterprise-ready and beat the shit
        out of immeasurably ugly SOAP.

        Being pragmatic and harsh, I'd propose the following changes:

        1. Drop all 1.0 compatibility. No, really. How many people do really
        use JSON-RPC 1.0? Specifically, let's forget "id" element.

        \

        2. Drop requirements on HTTP headers. It's quite enough for each side
        to receive parsable JSON - then we assume transport layer is ok.
        3. Differentiate strictly between "GET/POST" request types. They are
        NOT completely interchangeable and cause confusion. POST should be the
        main method, because it's all about JSON. GET - is alternative way
        (maybe even another spec, JSON-RPC-Lite)
        .
        4. "params" should be of any type. Int, String and Null should be ok.
        Let server decide how to process it.
        5. Add optional "auth" parameter to request, of arbitrary type. For
        those dudes who don't want to deal with HTTP auth and would like to
        use session ID or sumfin else.

        We need to move forward. Such a brilliant chance to improve Web
        Services world shouldn't be missed.





      • Jan-Klaas Kollhof
        Hey, ... I, Jan-Klaas Kollhof, created the 1.0 specs. Atif has been the driving force behind the 1.1 specs. Unfortunately, I have had little time in the past
        Message 3 of 8 , Jun 6, 2007
        • 0 Attachment
          Hey,

          > who are the stake
          > holders here and can we divide some of the work up? is there any
          > formal process what so ever for responding to issues publicly?


          I, Jan-Klaas Kollhof, created the 1.0 specs.
          Atif has been the driving force behind the 1.1 specs.

          Unfortunately, I have had little time in the past months to
          participate in the JSON-RPC discussions/specs.

          Any volunteers to help out are more than welcome to do so.
          I can add accounts for trac and sft on json-rpc.org if needed.


          > I'd like to add one point, get off of yahoo groups. I can suggest
          various alternatives and may even be
          > able to get IT here at the Open Source Applications Foundation to set
          > up a mailman account for the json-rpc community, we already host an
          > IETF working group and some other open standards/projects group lists
          > that aren't directly funded by OSAF.

          I could install a mailinglist on json-rpc.org or add a forward address
          to a list hosteted somewhere else.


          Jan
        • r.koebler
          hi, ... did you read http://84.16.237.14/jsonrpc/ ? ... hmm, I don t think so. in terms of RPC, what would i.e. a string mean? that it s the only parameter to
          Message 4 of 8 , Jun 6, 2007
          • 0 Attachment
            hi,

            > 1.1 spec STILL isn't complete, and is too complex, in my opinion.
            did you read http://84.16.237.14/jsonrpc/ ?

            > 4. "params" should be of any type. Int, String and Null should be ok.
            > Let server decide how to process it.
            hmm, I don't think so. in terms of RPC, what would i.e. a string mean?
            that it's the only parameter to a procedure call? I think always using
            an array/object is cleaner.


            regards,
            Roland
          • Jorge Vargas
            ... I think this should be made optional. I got a project in which I m implementing json-rpc over tcp (I have a patched version of json-rpc.org code with it)
            Message 5 of 8 , Jun 14, 2007
            • 0 Attachment
              On 6/5/07, Mikeal Rogers <mikeal@...> wrote:
              >
              > I'm in 100% agreement with 1, the spec not being finished a big problem, who
              > is responsible for editing the spec? who are the stake holders here and can
              > we divide some of the work up? is there any formal process what so ever for
              > responding to issues publicly?
              >
              > I'm in strong disagreement with 2, these headers are absolutely necessary
              > for proper interop with REST based services and without them this standard
              > will never have a chance at making it through the IETF or a comparable
              > standards certification process.
              >
              I think this should be made optional. I got a project in which I'm
              implementing json-rpc over tcp (I have a patched version of
              json-rpc.org code with it)

              > On point 3, I too think the use of GET should be a separate specification.
              > Breaking the current spec in to two different use cases is draining and
              > adding a lot of unnecessary complexity.
              >
              +1
              > I don't see the use case for params being any type other than array or
              > object?
              >
              me neither the overhead of sending a json-rpc package is way too much
              for just seding int.

              > I also don't see the use case for auth in the parameters, auth should be
              > handled at the HTTP layer which has all the protocol support necessary. If
              > they can't "deal" with HTTP auth (who are these people?), then they can add
              > an arbitrary auth parameter to the params list of all the method calls and
              > parse it out before dispatching the remote method, this will end up being
              > more interoperable than having a base level attribute with no specific
              > semantics other than "it might hold auth or session data in some format" and
              > we don't want to add a bunch of extra auth semantics to the current spec.
              >
              > I'd like to add one point, get off of yahoo groups. The formatting of these
              > emails make responses difficult when the html bodies barely parse. Not to
              > mention the annoying ads that are added to each email. My participation has
              > been lessened by the fact that using yahoo groups is painful. I can suggest
              > various alternatives and may even be able to get IT here at the Open Source
              > Applications Foundation to set up a mailman account for the json-rpc
              > community, we already host an IETF working group and some other open
              > standards/projects group lists that aren't directly funded by OSAF.
              >
              yes pleeease googlegroups are good I suggest we move overthere.
              > -Mikeal
              >
              > On Jun 1, 2007, at 5:22 AM, konstantin_yegupov wrote:
              >
              >
              >
              > 1.1 spec STILL isn't complete, and is too complex, in my opinion.
              >
              > An we NEED it finished, to make it enterprise-ready and beat the shit
              > out of immeasurably ugly SOAP.
              >
              > Being pragmatic and harsh, I'd propose the following changes:
              >
              > 1. Drop all 1.0 compatibility. No, really. How many people do really
              > use JSON-RPC 1.0? Specifically, let's forget "id" element.
              > \
              >
              >
              >
              >
              >
              > 2. Drop requirements on HTTP headers. It's quite enough for each side
              > to receive parsable JSON - then we assume transport layer is ok.
              > 3. Differentiate strictly between "GET/POST" request types. They are
              > NOT completely interchangeable and cause confusion. POST should be the
              > main method, because it's all about JSON. GET - is alternative way
              > (maybe even another spec, JSON-RPC-Lite).
              > 4. "params" should be of any type. Int, String and Null should be ok.
              > Let server decide how to process it.
              > 5. Add optional "auth" parameter to request, of arbitrary type. For
              > those dudes who don't want to deal with HTTP auth and would like to
              > use session ID or sumfin else.
              >
              > We need to move forward. Such a brilliant chance to improve Web
              > Services world shouldn't be missed.
              >
              >
              >
              >
              >
              >
              >
            • Jorge Vargas
              ... I ll like to work on that. I can give a nice maintenance run to the trac, milestones, versions, we could even install the
              Message 6 of 8 , Jun 14, 2007
              • 0 Attachment
                On 6/6/07, Jan-Klaas Kollhof <keyjaque@...> wrote:
                >
                >
                >
                >
                >
                >
                > Hey,
                >
                > > who are the stake
                > > holders here and can we divide some of the work up? is there any
                > > formal process what so ever for responding to issues publicly?
                >
                > I, Jan-Klaas Kollhof, created the 1.0 specs.
                > Atif has been the driving force behind the 1.1 specs.
                >
                > Unfortunately, I have had little time in the past months to
                > participate in the JSON-RPC discussions/specs.
                >
                > Any volunteers to help out are more than welcome to do so.
                > I can add accounts for trac and sft on json-rpc.org if needed.
                >
                I'll like to work on that. I can give a nice maintenance run to the
                trac, milestones, versions, we could even install the
                http://trac-hacks.org/wiki/AccountManagerPlugin plugin so everyone
                that needs an account can get it without admin intervention.

                > > I'd like to add one point, get off of yahoo groups. I can suggest
                > various alternatives and may even be
                > > able to get IT here at the Open Source Applications Foundation to set
                > > up a mailman account for the json-rpc community, we already host an
                > > IETF working group and some other open standards/projects group lists
                > > that aren't directly funded by OSAF.
                >
                > I could install a mailinglist on json-rpc.org or add a forward address
                > to a list hosteted somewhere else.
                or get a googlegroup it's email formatting is sane.
                >
                > Jan
                >
                >
              • Mikeal Rogers
                ... Only json-rpc over HTTP is covered in the new spec. If you re doing it over TCP then you re free to disregard HTTP specific areas of the spec, like HTTP
                Message 7 of 8 , Jun 14, 2007
                • 0 Attachment
                  > I'm in strong disagreement with 2, these headers are absolutely necessary
                  > for proper interop with REST based services and without them this standard
                  > will never have a chance at making it through the IETF or a comparable
                  > standards certification process.
                  >
                  I think this should be made optional. I got a project in which I'm
                  implementing json-rpc over tcp (I have a patched version of
                  json-rpc.org code with it)

                  Only json-rpc over HTTP is covered in the new spec. If you're doing it over TCP then you're free to disregard HTTP specific areas of the spec, like HTTP headers.

                  Nobody is saying you MUST use json-rpc over HTTP, we're just saying the spec that is being worked on now is only going to try and cover the case of json-rpc over HTTP. 

                  -Mikeal
                • r.koebler
                  ... yes, but I separated HTTP from the spec in http://84.16.237.14/jsonrpc/. and I and many others think http://84.16.237.14/jsonrpc/ is a major improvement to
                  Message 8 of 8 , Jun 15, 2007
                  • 0 Attachment
                    > Only json-rpc over HTTP is covered in the new spec.
                    yes, but I separated HTTP from the spec in http://84.16.237.14/jsonrpc/.

                    and I and many others think http://84.16.237.14/jsonrpc/ is a major
                    improvement to the current spec, so I would suggest to further work on
                    base of this suggestion.

                    > Nobody is saying you MUST use json-rpc over HTTP, we're just saying
                    > the spec that is being worked on now is only going to try and cover
                    > the case of json-rpc over HTTP.
                    which is really not necessary, see my spec.

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