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

python client code

Expand Messages
  • m h
    Hello Folks- I m trying to make a wsgi app for json-rpc. Is there any client side code available? I noticed that the proxy stuff didn t appear to be
    Message 1 of 10 , Mar 15, 2006
      Hello Folks-

      I'm trying to make a wsgi app for json-rpc. Is there any client side
      code available? I noticed that the proxy stuff didn't appear to be
      complete.

      Can someone provide an example of client side access?

      I'd like to make some testcases...

      thanks

      matt
    • Jan-Klaas Kollhof
      ... No, my new python impl has no client side stuff yet. I do have some older code laying around which had a ServiceProxy class. If I find it I could send it
      Message 2 of 10 , Mar 16, 2006
        > I'm trying to make a wsgi app for json-rpc. Is there any client side
        > code available? I noticed that the proxy stuff didn't appear to be
        > complete.

        No, my new python impl has no client side stuff yet.
        I do have some older code laying around which had a ServiceProxy class.
        If I find it I could send it to you.

        Jan
      • m h
        ... Jan- Thanks for the response. I d very much like to look at the previous code, if you or anyone else on the list can send it to me;) So since half the
        Message 3 of 10 , Mar 16, 2006
          On 3/16/06, Jan-Klaas Kollhof <keyjaque@...> wrote:
          >
          > > I'm trying to make a wsgi app for json-rpc. Is there any client side
          > > code available? I noticed that the proxy stuff didn't appear to be
          > > complete.
          >
          > No, my new python impl has no client side stuff yet.
          > I do have some older code laying around which had a ServiceProxy class.
          > If I find it I could send it to you.
          >

          Jan-
          Thanks for the response. I'd very much like to look at the previous
          code, if you or anyone else on the list can send it to me;)

          So since half the point of json is to have js talk to the endpoints, I
          decided to use an existing client that I thought should work as a
          testcase. (Rather than implementing a client that I'm not completely
          sure how it should work from reading the spec and having it talk to my
          server, that I'm not completely sure works either (since I haven't
          tested it yet ;)) ). So, I took the client code (javascript) from the
          Java-json-rpc page (http://oss.metaparadigm.com/jsonrpc-cvs/test.jsp )
          (redirecting their call to my endpoint). I ran into a few issues:

          * The first was in SimpleConnectionHandler.handlePartialData it is
          assumming that the dta will end in "\0" (the call coming from my page
          didn't, so it never got around to processing my request). I added a
          quick check [read hack] to append "\0" to the end if it wasn't there
          and got around that issue.

          * So when it finally was able to process my request, which happened to
          be system.listMethods, the lookup in getMethodByName failed.

          Was listMethods previously implemented as well? If so, I'd love to
          see them if you have the code. If not, are you planning on
          implementing it? I noticed it is not in the spec, but for people
          coming from a xmlrpc world it'd be nice. (Plus the java folks already
          have it)

          thanks
          matt
        • Jan-Klaas Kollhof
          ... The 0 is not standard in any way, actually the specs do not mention how multiple messages are seperated, it just said there can be multiple messages one
          Message 4 of 10 , Mar 17, 2006
            > Jan-
            >* The first was in SimpleConnectionHandler.handlePartialData it is
            > assumming that the dta will end in "\0" (the call coming from my page
            > didn't, so it never got around to processing my request). I added a
            > quick check [read hack] to append "\0" to the end if it wasn't there
            > and got around that issue.

            The \0 is not standard in any way, actually the specs do not mention
            how multiple messages are seperated, it just said there can be
            multiple messages one after another.
            The reason why teh new python code has a \0 to seperate messages is
            that I am working on a JSON-RPC over TCP impl that uses Flash
            XMLSockets that need \0 between messages.
            The HTTP handlers should not use \0 as message delimiter but rahter
            use \n. see:
            http://json-rpc.org/browser/trunk/jsonrpc/apacheServiceHandler.py#L31
            and:
            http://json-rpc.org/browser/trunk/jsonrpc/cgihandler.py#L29

            if you see that that is not working you might want to raise a ticket
            and I will have a check and fix it.
            2nd thought, I think it is a bug and I need to add a delimiter on the
            server side for HTTP data to make sure single messages have one at teh
            end no matter if the client added it or not.

            The python impl. needs some kind of message delimiter and I think that
            the specs should define a unique delimiter for multiple messages.


            The impl. at http://jsolait.net should always work with the current
            python impl. ast json-rpc.org (well, they are both my projects, so one
            would assume that they should be compatible ;) )

            >
            > * So when it finally was able to process my request, which happened to
            > be system.listMethods, the lookup in getMethodByName failed.
            >
            > Was listMethods previously implemented as well? If so, I'd love to
            > see them if you have the code. If not, are you planning on
            > implementing it? I noticed it is not in the spec, but for people
            > coming from a xmlrpc world it'd be nice. (Plus the java folks
            already have it)

            No, system.* is not implemented but should be realy easy to do.
            for now you could create a mixin class for your service that would
            implement the system object. It should be pretty simple.

            I will look for the old code and post a link later.


            Jan
          • m h
            ... I see that in sendMessage you use self.messageDelimiter, but in handlePartialData there are appearances of 0 that should be using
            Message 5 of 10 , Mar 20, 2006
              On 3/17/06, Jan-Klaas Kollhof <keyjaque@...> wrote:
              > Jan-

              >* The first was in SimpleConnectionHandler.handlePartialData it is
              > assumming that the dta will end in "\0" (the call coming from my page
              > didn't, so it never got around to processing my request).  I added a
              > quick check [read hack] to append "\0" to the end if it wasn't there
              > and got around that issue.

              The \0 is not standard in any way, actually the specs do not mention
              how multiple messages are seperated, it just said there can be
              multiple messages one after another.
              The reason why teh new python code has a \0 to seperate messages is
              that I am working on a JSON-RPC over TCP impl that uses Flash
              XMLSockets that need \0 between messages.
              The HTTP handlers should not use \0 as message delimiter but rahter
              use \n. see:
              http://json-rpc.org/browser/trunk/jsonrpc/apacheServiceHandler.py#L31
              and:
              http://json-rpc.org/browser/trunk/jsonrpc/cgihandler.py#L29


              I see that in sendMessage you use  self.messageDelimiter, but in handlePartialData there are appearances of "\0" that should be using self.messageDelimiter.  (Or maybe they shouldn't but setting messageDelimiter has no effect on incoming data, only outgoing)

              if you see that that is not working you might want to raise a ticket
              and I will have a check and fix it.
              2nd thought, I think it is a bug and I need to add a delimiter on the
              server side for HTTP data to make sure single messages have one at teh
              end no matter if the client added it or not.

              Agreed.
               

              The python impl. needs some kind of message delimiter and I think that
              the specs should define a unique delimiter for multiple messages.

              Why not encode the messages as a list (in json)?

              The impl. at http://jsolait.net should always work with the current
              python impl. ast json-rpc.org (well, they are both my projects, so one
              would assume that they should be compatible ;) )


              Fair enough, I'll try jsolait.  Thanks for the pointer.  I'm used to Mochikit.  Would you care to compare/contrast jsolait.  Among python web people it appears that Mochi and Dojo have the most traction....

              >
              > * So when it finally was able to process my request, which happened to
              > be system.listMethods, the lookup in getMethodByName failed.
              >
              > Was listMethods previously implemented as well?  If so, I'd love to
              > see them if you have the code.  If not, are you planning on
              > implementing it?  I noticed it is not in the spec, but for people
              > coming from a xmlrpc world it'd be nice.  (Plus the java folks
              already have it)

              No, system.* is not implemented but should be realy easy to do.
              for now you could create a mixin class for your service that would
              implement the system object. It should be pretty simple.

              Shouldn't this be part of the spec?
               

              I will look for the old code and post a link later.

              Thanks for your response Jan.  I think json-rpc shows a  lot of promise but it would be nice if the spec were a little more complete and there was a reference implementation, so that potential users could try it out quickly. 

              matt


            • m h
              I ve created two bugs on trac. One to address the 0 issue and another one about registering functions as services. So is anyone out there using this (the
              Message 6 of 10 , Mar 21, 2006
                I've created two bugs on trac. One to address the "\0" issue and
                another one about registering functions as services.

                So is anyone out there using this (the python version)? Are people
                planning on using it? Just curious...

                cheers,

                -matt
              • Jan-Klaas Kollhof
                ... That s a bug. I will fix that. What it does it just takes n and 0 as delimiters. it should also take the delimiter into account. ... Yes, that has been
                Message 7 of 10 , Mar 22, 2006
                  >
                  > I see that in sendMessage you use self.messageDelimiter, but in
                  > handlePartialData there are appearances of "\0" that should be using
                  > self.messageDelimiter. (Or maybe they shouldn't but setting
                  > messageDelimiter has no effect on incoming data, only outgoing)

                  That's a bug. I will fix that.
                  What it does it just takes \n and \0 as delimiters. it should also
                  take the delimiter into account.


                  > Why not encode the messages as a list (in json)?

                  Yes, that has been suggested before.

                  I probably should not have any delimiters in it as the specs don't
                  define any.
                  I needed them though for a specific implementation. I probably should
                  have not put the code into the base class as that should implement the
                  specs correctly.



                  > > No, system.* is not implemented but should be realy easy to do.
                  > > for now you could create a mixin class for your service that would
                  > > implement the system object. It should be pretty simple.
                  > >
                  >
                  > Shouldn't this be part of the spec?
                  >

                  Introspection should, yes. But it probably be part of a sub spec or
                  something to keep it seperate from the basic protocoll.


                  > Thanks for your response Jan. I think json-rpc shows a lot of
                  promise but it would be nice if the spec were a little more complete
                  and there was a reference implementation, so that potential users
                  could try it out quickly.

                  Someone please warp space and time so I have more freetime to work on
                  these sort of things.


                  Jan
                • Johan Sundström
                  ... Based on my experiences of jsolait from a year ago, and highly prejudiced: Mochikit/Dojo: unobtrusive module systems, adding framework on the side that you
                  Message 8 of 10 , Mar 25, 2006
                    > Fair enough, I'll try jsolait. Thanks for the pointer. I'm used to
                    > Mochikit. Would you care to compare/contrast jsolait. Among
                    > python web people it appears that Mochi and Dojo have the
                    > most traction....

                    Based on my experiences of jsolait from a year ago, and highly prejudiced:

                    Mochikit/Dojo: unobtrusive module systems, adding framework on the
                    side that you may choose to put to use to package your own code as
                    modules, and use Dojo/Mochikit modules from yours. Mature, documented,
                    tested, upstream behind-the-curtains internal API code spelled
                    correctly.

                    Jsolait: obtrusive framework where the module system hides backtraces
                    from the console, showing the source of most errors in module code as
                    some inheritModule call, and possibly just of a module that inherited
                    the problem from some other module in any number of inheritance
                    indirections. External APIs are correctly spelled, but the internals
                    are full of methods and properties with more dubious names.

                    Mini-review from the time, essentially repeating the above:
                    http://ecmanaut.blogspot.com/2005/12/svg-collaborative-canvas.html

                    Jsolait does have some useful methods stashed away in its module
                    system, but I would rather rip them out and liberate them from the
                    system than use them verbatim through the framework they are tied up
                    in.

                    --
                    / Johan Sundström, http://ecmanaut.blogspot.com/
                  • m h
                    Johan- Thanks for your feedback. I ll probably use mochi or dojo eventually. Right now I want to make sure that I m doing the backend right (since I m doing a
                    Message 9 of 10 , Mar 25, 2006
                      Johan-

                      Thanks for your feedback.  I'll probably use mochi or dojo eventually.  Right now I want to make sure that I'm doing the backend right (since I'm doing a WSGI adapter for it) and need to have a front client that I know works with jsonrpc.  I have the basic wsgi stuff working.  I also now have python client code.  I need clean a few things up but it is mostly working.

                      Jan- Let me know if you are interested in such code.  Otherwise I'll put it up on my blog or somewhere else.

                      -matt

                      On 3/25/06, Johan Sundström <oyasumi@...> wrote:
                      > Fair enough, I'll try jsolait.  Thanks for the pointer. I'm used to
                      > Mochikit.  Would you care to compare/contrast jsolait.  Among
                      > python web people it appears that Mochi and Dojo have the
                      > most traction....

                      Based on my experiences of jsolait from a year ago, and highly prejudiced:

                      Mochikit/Dojo: unobtrusive module systems, adding framework on the
                      side that you may choose to put to use to package your own code as
                      modules, and use Dojo/Mochikit modules from yours. Mature, documented,
                      tested, upstream behind-the-curtains internal API code spelled
                      correctly.

                      Jsolait: obtrusive framework where the module system hides backtraces
                      from the console, showing the source of most errors in module code as
                      some inheritModule call, and possibly just of a module that inherited
                      the problem from some other module in any number of inheritance
                      indirections. External APIs are correctly spelled, but the internals
                      are full of methods and properties with more dubious names.

                      Mini-review from the time, essentially repeating the above:
                      http://ecmanaut.blogspot.com/2005/12/svg-collaborative-canvas.html

                      Jsolait does have some useful methods stashed away in its module
                      system, but I would rather rip them out and liberate them from the
                      system than use them verbatim through the framework they are tied up
                      in.

                      --
                      / Johan Sundström, http://ecmanaut.blogspot.com/


                      SPONSORED LINKS
                      Protocol analyzer Ssl protocol Protocol converter
                      Sip protocol Protocol analysis Protocol


                      YAHOO! GROUPS LINKS




                    • Jan-Klaas Kollhof
                      ... backtraces from the console, showing the source of most errors in module code as some inheritModule call, and possibly just of a module that inherited the
                      Message 10 of 10 , Mar 27, 2006
                        > Jsolait: obtrusive framework where the module system hides
                        backtraces from the console, showing the source of most errors in
                        module code as
                        some inheritModule call, and possibly just of a module that inherited
                        the problem from some other module in any number of inheritance
                        indirections.

                        The exception mechanism is implemented in such a way that a module
                        specific exception class is used for any exception thrown inside a
                        certain module.
                        Usually any exception contains a property which is the exception that
                        might have caused the exception (if available). This way one can get
                        to an error trace without having a debugger and easyly find out in
                        what module the exception was thrown and what the underlying cause of
                        it was.
                        At least that was the thought behind implementing it that way.


                        > External APIs are correctly spelled, but the internals
                        > are full of methods and properties with more dubious names.

                        Hmmm, I must admit I am a terrible speller. Unless people point out
                        bad spelling or naming by adding a ticket on jsolait.net or dropping a
                        mail or even a patch it will take some time for me to fix those.
                        Same for json-rpc.org
                        Since using a wiki I have seen a number of changes on both sites where
                        people have fixed my bad writing, I really appreciate that!


                        > Mini-review from the time, essentially repeating the above:
                        > http://ecmanaut.blogspot.com/2005/12/svg-collaborative-canvas.html

                        :) the canvas is rather simple example and riped out of a larger
                        discontinued project: http://jan.kollhof.net/publications/svgopen2004.html


                        > Jsolait does have some useful methods stashed away in its module
                        > system, but I would rather rip them out and liberate them from the
                        > system than use them verbatim through the framework they are tied up
                        > in.

                        Besides developing jsolait when I find some time for it I am using it
                        at my current job for larger applications, mainly working with an
                        embedded IE component. There is a lot of shared code that is currently
                        used by different parts of the application. It used to be that the
                        shared code would be a collection of scripts that exposed quite a
                        number of global methods and objects which ended up being a bit of a
                        mess.
                        With jsolait's module mechanism I am able to have only the core
                        functionality exposed to the global namespace. Each module can contain
                        private data and functionality...
                        Dependencies are resolved much easier now as well as I don't need to
                        know in the HTML page what they are, all I do is import the module
                        that handles the page's UI and the rest is handled by jsolait.
                        Modularizing the shared code using jsolait has been a great help so
                        far. All the code I am working on is written in jsolait.
                        I have not run into any problems with the module mechanism yet,
                        neither for debugging nor for performance or stability.

                        Sorry, I may sound a bit defencive and I am surely a bit subjective.

                        :)

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