Loading ...
Sorry, an error occurred while loading the content.
Skip to search.
 

RE: [json-rpc] Why I will not follow the new draft

Expand Messages
  • Atif Aziz
    ... On a separate note, in October I ll be at NYCBSDCon and The Ajax Experience in case anyone from the json-rpc list is interested getting together to hash
    Message 1 of 11 , Oct 2, 2006

      >>  

      On a separate note, in October I'll be at NYCBSDCon and The Ajax Experience in case anyone from the json-rpc list is interested getting together to hash over on going json-rpc issues

      <<  

       

      Why not form a remote working group that tries to get through some of the tricky/thorny/edge issues quicker in meetings? While discussion groups are great for keeping track of dialog, the downside is that the dialog tends to be thin and spread over several days depending on people’s schedules. One way how this could work is if some kind soul (or their fat farm) could sponsor a conference call. Opinions?

       


      From: json-rpc@yahoogroups.com [mailto: json-rpc@yahoogroups.com ] On Behalf Of Matt
      Sent: Thursday, September 28, 2006 5:11 PM
      To: json-rpc@yahoogroups.com
      Subject: Re: [json-rpc] Why I will not follow the new draft

       

      >10. Service Description

      >id REQUIRED.   This will not be implemented. I see no benefit
      from
      >implementing this. It is also very difficult for us to support this,
      >especially in embedded systems.

      Why exactly would this be difficult?

      >Only HTTP errors will be sent with a non 200 HTTP response. Errors
      >detected by the parser, the JSON-RPC logic or the JSON server methods
      >will have a 200 HTTP response message.

      Would you mind pointing out the reference in the working draft?



      (On a separate note, in October I'll be at NYCBSDCon and The Ajax Experience in case anyone from the json-rpc list is interested getting together to hash over on going json-rpc issues)
      --
      Matthew P. C. Morley
      MPCM Technologies Inc.

    • Atif Aziz
      ... error parsing the JSON, etc. We will return 200 for all errors not strictly related to the web-server. The 7.4. Error Object is all that is needed.
      Message 2 of 11 , Oct 2, 2006

        >>  

        error parsing the JSON, etc. We will return 200 for all errors not strictly related to the web-server. The 7.4. Error Object is all that is needed.

        <<  

         

        Are you taking this route due to technical and implementation difficulties or because you truly believe that 7.4 (Error Object) is all that is needed and the rest adds unnecessary fluff? HTTP errors are not related to web servers only. All parties in the pipeline, from the client to intermediaries to the final request handler must pay attention to HTTP status codes. Why lie to your clients when an error is an indeed error?

         


        From: json-rpc@yahoogroups.com [mailto: json-rpc@yahoogroups.com ] On Behalf Of Wilfred Nilsen
        Sent: Thursday, September 28, 2006 9:42 PM
        To: json-rpc@yahoogroups.com
        Subject: [json-rpc] Re: Why I will not follow the new draft

         

        > >10. Service Description

        > >id REQUIRED. This will not be implemented. I see no benefit from
        > >implementing this. It is also very difficult for us to support this,
        > >especially in embedded systems.
        >
        > Why exactly would this be difficult?

        Well, maybe it is not difficult, but I see no reason for this
        attribute as the URL to the service is unique i.e. you found the
        service using a URL, why do you need an additional ID?

        >
        > >Only HTTP errors will be sent with a non 200 HTTP response. Errors
        > >detected by the parser, the JSON-RPC logic or the JSON server methods
        > >will have a 200 HTTP response message.
        >
        > Would you mind pointing out the reference in the working draft?

        7.1. HTTP Status Code Requirements
        Unless noted otherwise, a status code of 500 (Internal Server Error)
        MUST be used under the following conditions:

        error parsing the JSON, etc. We will return 200 for all errors not
        strictly related to the web-server. The 7.4. Error Object is all that
        is needed.

      • Jeffrey Damick
        That would be great for those of us who can t make it, i will talk to my fat farm about sponsoring a conference call. -jeff
        Message 3 of 11 , Oct 2, 2006
          That would be great for those of us who can't make it, i will talk to my "fat farm" about sponsoring a conference call.

          -jeff

          On 10/2/06, Atif Aziz <atif.aziz@...> wrote:

          >> 

          On a separate note, in October I'll be at NYCBSDCon and The Ajax Experience in case anyone from the json-rpc list is interested getting together to hash over on going json-rpc issues

          << 

           

          Why not form a remote working group that tries to get through some of the tricky/thorny/edge issues quicker in meetings? While discussion groups are great for keeping track of dialog, the downside is that the dialog tends to be thin and spread over several days depending on people's schedules. One way how this could work is if some kind soul (or their fat farm) could sponsor a conference call. Opinions?

           


          From: json-rpc@yahoogroup s.com [mailto:json-rpc@yahoogroup s.com] On Behalf Of Matt
          Sent: Thursday, September 28, 2006 5:11 PM
          To: json-rpc@yahoogroups.com
          Subject: Re: [json-rpc] Why I will not follow the new draft

           

          >10. Service Description
          >id REQUIRED.   This will not be implemented. I see no benefit from
          >implementing this. It is also very difficult for us to support this,
          >especially in embedded systems.

          Why exactly would this be difficult?

          >Only HTTP errors will be sent with a non 200 HTTP response. Errors
          >detected by the parser, the JSON-RPC logic or the JSON server methods
          >will have a 200 HTTP response message.

          Would you mind pointing out the reference in the working draft?



          (On a separate note, in October I'll be at NYCBSDCon and The Ajax Experience in case anyone from the json-rpc list is interested getting together to hash over on going json-rpc issues)
          --
          Matthew P. C. Morley
          MPCM Technologies Inc.


        • Atif Aziz
          That d be grand, Jeff! Thanks for volunteering to try and set this up. Should I setup a database on the group to see how many and who d like to attend? Would
          Message 4 of 11 , Oct 2, 2006

            That’d be grand, Jeff! Thanks for volunteering to try and set this up. Should I setup a database on the group to see how many and who’d like to attend? Would that help in planning the capacity?

             

            Thanks,

            - Atif

             


            From: Jeffrey Damick [mailto:jeffreydamick@...]
            Sent: Monday, October 02, 2006 3:27 PM
            To: json-rpc@yahoogroups.com; Atif Aziz
            Subject: Re: [json-rpc] Why I will not follow the new draft

             

            That would be great for those of us who can't make it, i will talk to my "fat farm" about sponsoring a conference call.

            -jeff

            On 10/2/06, Atif Aziz <atif.aziz@...> wrote:

            >> 

            On a separate note, in October I'll be at NYCBSDCon and The Ajax Experience in case anyone from the json-rpc list is interested getting together to hash over on going json-rpc issues

            << 

             

            Why not form a remote working group that tries to get through some of the tricky/thorny/edge issues quicker in meetings? While discussion groups are great for keeping track of dialog, the downside is that the dialog tends to be thin and spread over several days depending on people's schedules. One way how this could work is if some kind soul (or their fat farm) could sponsor a conference call. Opinions?

             


            From: json-rpc@yahoogroup s.com [mailto:json-rpc@yahoogroup s.com] On Behalf Of Matt
            Sent: Thursday, September 28, 2006 5:11 PM
            To: json-rpc@yahoogroups.com
            Subject: Re: [json-rpc] Why I will not follow the new draft

             

            >10. Service Description

            >id REQUIRED.   This will not be implemented. I see
            no benefit from
            >implementing this. It is also very difficult for us to
            support this,
            >especially in embedded systems.

            Why exactly would this be difficult?

            >Only HTTP errors will be sent with a non 200 HTTP response.
            Errors
            >detected by the parser, the JSON-RPC logic or the JSON server
            methods
            >will have a 200 HTTP response message.

            Would you mind pointing out the reference in the working draft?



            (On a separate note, in October I'll be at NYCBSDCon and The Ajax Experience in case anyone from the json-rpc list is interested getting together to hash over on going json-rpc issues)
            --
            Matthew P. C. Morley
            MPCM Technologies Inc.

             

          • Wilfred Nilsen
            I am sorry for not responding before now. ... YES :-)
            Message 5 of 11 , Oct 2, 2006
              I am sorry for not responding before now.


              > The last line ['The 7.4. Error Object...'] does say that an error
              > object should be used for json related items, so your objection is
              > just to the HTTP 500 on json parse errors (as do I)?

              YES :-)
            • Wilfred Nilsen
              ... No I do not have any technical problems using either solution, though the JavaScript client library I built is now easier since I separate between HTTP
              Message 6 of 11 , Oct 2, 2006
                >
                >
                > Are you taking this route due to technical and implementation
                > difficulties or because you truly believe that 7.4 (Error Object) is all
                > that is needed and the rest adds unnecessary fluff? HTTP errors are not
                > related to web servers only. All parties in the pipeline, from the
                > client to intermediaries to the final request handler must pay attention
                > to HTTP status codes. Why lie to your clients when an error is an indeed
                > error?

                No I do not have any technical problems using either solution, though
                the JavaScript client library I built is now easier since I separate
                between HTTP errors and JSON errors.
                The most common HTTP errors the client library must deal with are 401
                and 403, which has to do with how we do the security. I prefer to
                separate the logic for HTTP related issues and JSON related issues. It
                is simply cleaner.
              Your message has been successfully submitted and would be delivered to recipients shortly.