From: Adams C. <chr...@so...> - 2011-04-19 14:53:06
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I intend to build a RPC server and should use JSON-RPC 2.0 (as specified in http://groups.google.com/group/json-rpc/web/json-rpc-2-0). Now my question is: what's the state of yaws_rpc? Which version of JSON-RPC is supported? If it's not (yet) 2.0, are there plans to upgrade or alternative solutions? Regards, Christian Adams - -- CHRISTIAN ADAMS Software Systems Engineer Fon: +49 651 99554792 chr...@so... SOL VENETUS Software GmbH Sebastian-Kneipp-Str. 2 - 86482 Aystetten - Germany Fon: +49 170 7762480 Fax: +49 821 4865786 Geschäftsführer: Benjamin Hilbig Sitz der Gesellschaft: Aystetten Amtsgericht Augsburg, HRB 24559 USt-IdNr.: DE267014985 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk2tnCgACgkQr81gVylJyzECzQCfSyeUwmIaC+QA6NfnsTWsR5ez lRYAmgMbYYR+YkIMGaoIZkcmquM6FXPb =mpu7 -----END PGP SIGNATURE----- |
From: Steve V. <vi...@ie...> - 2011-04-19 16:08:44
|
On Tue, Apr 19, 2011 at 10:28 AM, Adams Christian <chr...@so...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I intend to build a RPC server and should use JSON-RPC 2.0 (as specified in http://groups.google.com/group/json-rpc/web/json-rpc-2-0). > Now my question is: what's the state of yaws_rpc? I don't think it's been touched in awhile, and nobody complains about it. That either means whoever is using it is totally happy with it, or nobody's using it. :-) > Which version of JSON-RPC is supported? I assume it's 1.0. > If it's not (yet) 2.0, are there plans to upgrade or alternative solutions? i could likely be coerced into updating this. Are you a willing test volunteer? --steve |
From: Adams C. <chr...@so...> - 2011-04-21 08:31:33
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi Steve, >> If it's not (yet) 2.0, are there plans to upgrade or alternative solutions? > > i could likely be coerced into updating this. Are you a willing test volunteer? 'willing' sounds a little like 'victim' to me ;) however i would like to help you testing JSON-RPC 2.0 regards, christian CHRISTIAN ADAMS Software Systems Engineer Fon: +49 651 99554792 chr...@so... SOL VENETUS Software GmbH Sebastian-Kneipp-Str. 2 - 86482 Aystetten - Germany Fon: +49 170 7762480 Fax: +49 821 4865786 Geschäftsführer: Benjamin Hilbig Sitz der Gesellschaft: Aystetten Amtsgericht Augsburg, HRB 24559 USt-IdNr.: DE267014985 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk2v61kACgkQr81gVylJyzFy+QCg34iwpdgP4DCqFZacMYeBssAh H/gAoMVwQXC5/kA8/YXK3Z/KA8Va3wrO =7PtW -----END PGP SIGNATURE----- |
From: Fred D. <fr...@du...> - 2011-04-22 14:56:19
|
I could probably be convinced to participate, as well. I have an open app [1] that uses the current Yaws version of JSON-RPC, along with JSOlait on the client side. So I'd be interested in keeping my app up to date. -Fred [1] https://github.com/fadushin/lethe Adams Christian wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > hi Steve, > > >>> If it's not (yet) 2.0, are there plans to upgrade or alternative solutions? >>> >> i could likely be coerced into updating this. Are you a willing test volunteer? >> > > 'willing' sounds a little like 'victim' to me ;) > however i would like to help you testing JSON-RPC 2.0 > > regards, christian > > CHRISTIAN ADAMS > Software Systems Engineer > Fon: +49 651 99554792 > chr...@so... > > SOL VENETUS Software GmbH > Sebastian-Kneipp-Str. 2 - 86482 Aystetten - Germany > Fon: +49 170 7762480 > Fax: +49 821 4865786 > Geschäftsführer: Benjamin Hilbig > Sitz der Gesellschaft: Aystetten > Amtsgericht Augsburg, HRB 24559 > USt-IdNr.: DE267014985 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iEYEARECAAYFAk2v61kACgkQr81gVylJyzFy+QCg34iwpdgP4DCqFZacMYeBssAh > H/gAoMVwQXC5/kA8/YXK3Z/KA8Va3wrO > =7PtW > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Erlyaws-list mailing list > Erl...@li... > https://lists.sourceforge.net/lists/listinfo/erlyaws-list > |
From: Steve V. <vi...@ie...> - 2011-04-24 01:02:52
|
Thanks Christian and Fred. First problem though is issue #50: https://github.com/klacke/yaws/issues/50 Unfortunately not only does the existing json module use list_to_atom and therefore run the risk of filling the atom table, but it doesn't even pass its own internal tests. It looks like it was originally written to use UTF-16 but then someone later changed it to UTF-8 but apparently never ran or fixed the tests. :-( So, the first task is to create a new json2 module that fixes both these issues -- I'm working on this now. --steve On Fri, Apr 22, 2011 at 9:55 AM, Fred Dushin <fr...@du...> wrote: > > I could probably be convinced to participate, as well. I have an open > app [1] that uses the current Yaws version of JSON-RPC, along with > JSOlait on the client side. So I'd be interested in keeping my app up > to date. > > -Fred > > [1] https://github.com/fadushin/lethe > > Adams Christian wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> hi Steve, >> >> >>>> If it's not (yet) 2.0, are there plans to upgrade or alternative solutions? >>>> >>> i could likely be coerced into updating this. Are you a willing test volunteer? >>> >> >> 'willing' sounds a little like 'victim' to me ;) >> however i would like to help you testing JSON-RPC 2.0 >> >> regards, christian >> >> CHRISTIAN ADAMS >> Software Systems Engineer >> Fon: +49 651 99554792 >> chr...@so... >> >> SOL VENETUS Software GmbH >> Sebastian-Kneipp-Str. 2 - 86482 Aystetten - Germany >> Fon: +49 170 7762480 >> Fax: +49 821 4865786 >> Geschäftsführer: Benjamin Hilbig >> Sitz der Gesellschaft: Aystetten >> Amtsgericht Augsburg, HRB 24559 >> USt-IdNr.: DE267014985 >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.17 (Darwin) >> Comment: GPGTools - http://gpgtools.org >> >> iEYEARECAAYFAk2v61kACgkQr81gVylJyzFy+QCg34iwpdgP4DCqFZacMYeBssAh >> H/gAoMVwQXC5/kA8/YXK3Z/KA8Va3wrO >> =7PtW >> -----END PGP SIGNATURE----- >> >> ------------------------------------------------------------------------------ >> Benefiting from Server Virtualization: Beyond Initial Workload >> Consolidation -- Increasing the use of server virtualization is a top >> priority.Virtualization can reduce costs, simplify management, and improve >> application availability and disaster protection. Learn more about boosting >> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >> _______________________________________________ >> Erlyaws-list mailing list >> Erl...@li... >> https://lists.sourceforge.net/lists/listinfo/erlyaws-list >> > > > > ------------------------------------------------------------------------------ > Fulfilling the Lean Software Promise > Lean software platforms are now widely adopted and the benefits have been > demonstrated beyond question. Learn why your peers are replacing JEE > containers with lightweight application servers - and what you can gain > from the move. http://p.sf.net/sfu/vmware-sfemails > _______________________________________________ > Erlyaws-list mailing list > Erl...@li... > https://lists.sourceforge.net/lists/listinfo/erlyaws-list > |
From: Steve V. <vi...@ie...> - 2011-04-25 01:52:21
|
OK, I fixed issue #50 yesterday and pushed it to github. I'm now looking at the existing JSON-RPC support in yaws_rpc and it too calls list_to_atom on received strings, which is a no-no. I'll need to fix that as part of the JSON-RPC 2.0 update. --steve On Sat, Apr 23, 2011 at 9:02 PM, Steve Vinoski <vi...@ie...> wrote: > Thanks Christian and Fred. First problem though is issue #50: > > https://github.com/klacke/yaws/issues/50 > > Unfortunately not only does the existing json module use list_to_atom > and therefore run the risk of filling the atom table, but it doesn't > even pass its own internal tests. It looks like it was originally > written to use UTF-16 but then someone later changed it to UTF-8 but > apparently never ran or fixed the tests. :-( So, the first task is to > create a new json2 module that fixes both these issues -- I'm working > on this now. > > --steve > > On Fri, Apr 22, 2011 at 9:55 AM, Fred Dushin <fr...@du...> wrote: >> >> I could probably be convinced to participate, as well. I have an open >> app [1] that uses the current Yaws version of JSON-RPC, along with >> JSOlait on the client side. So I'd be interested in keeping my app up >> to date. >> >> -Fred >> >> [1] https://github.com/fadushin/lethe >> >> Adams Christian wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> hi Steve, >>> >>> >>>>> If it's not (yet) 2.0, are there plans to upgrade or alternative solutions? >>>>> >>>> i could likely be coerced into updating this. Are you a willing test volunteer? >>>> >>> >>> 'willing' sounds a little like 'victim' to me ;) >>> however i would like to help you testing JSON-RPC 2.0 >>> >>> regards, christian >>> >>> CHRISTIAN ADAMS >>> Software Systems Engineer >>> Fon: +49 651 99554792 >>> chr...@so... >>> >>> SOL VENETUS Software GmbH >>> Sebastian-Kneipp-Str. 2 - 86482 Aystetten - Germany >>> Fon: +49 170 7762480 >>> Fax: +49 821 4865786 >>> Geschäftsführer: Benjamin Hilbig >>> Sitz der Gesellschaft: Aystetten >>> Amtsgericht Augsburg, HRB 24559 >>> USt-IdNr.: DE267014985 >>> >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG/MacGPG2 v2.0.17 (Darwin) >>> Comment: GPGTools - http://gpgtools.org >>> >>> iEYEARECAAYFAk2v61kACgkQr81gVylJyzFy+QCg34iwpdgP4DCqFZacMYeBssAh >>> H/gAoMVwQXC5/kA8/YXK3Z/KA8Va3wrO >>> =7PtW >>> -----END PGP SIGNATURE----- >>> >>> ------------------------------------------------------------------------------ >>> Benefiting from Server Virtualization: Beyond Initial Workload >>> Consolidation -- Increasing the use of server virtualization is a top >>> priority.Virtualization can reduce costs, simplify management, and improve >>> application availability and disaster protection. Learn more about boosting >>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >>> _______________________________________________ >>> Erlyaws-list mailing list >>> Erl...@li... >>> https://lists.sourceforge.net/lists/listinfo/erlyaws-list >>> >> >> >> >> ------------------------------------------------------------------------------ >> Fulfilling the Lean Software Promise >> Lean software platforms are now widely adopted and the benefits have been >> demonstrated beyond question. Learn why your peers are replacing JEE >> containers with lightweight application servers - and what you can gain >> from the move. http://p.sf.net/sfu/vmware-sfemails >> _______________________________________________ >> Erlyaws-list mailing list >> Erl...@li... >> https://lists.sourceforge.net/lists/listinfo/erlyaws-list >> > |
From: Claes W. <kl...@ta...> - 2011-04-25 17:29:35
|
On 04/25/2011 03:52 AM, Steve Vinoski wrote: > OK, I fixed issue #50 yesterday and pushed it to github. I'm now > looking at the existing JSON-RPC support in yaws_rpc and it too calls > list_to_atom on received strings, which is a no-no. I'll need to fix > that as part of the JSON-RPC 2.0 update. An alternative, which I'm not sure will work here, is list_to_existing_atom/1, At Tail-f, we use that quite a lot. /klacke |
From: Steve V. <vi...@ie...> - 2011-04-25 17:32:59
|
On Mon, Apr 25, 2011 at 1:29 PM, Claes Wikstrom <kl...@ta...> wrote: > On 04/25/2011 03:52 AM, Steve Vinoski wrote: >> OK, I fixed issue #50 yesterday and pushed it to github. I'm now >> looking at the existing JSON-RPC support in yaws_rpc and it too calls >> list_to_atom on received strings, which is a no-no. I'll need to fix >> that as part of the JSON-RPC 2.0 update. > > An alternative, which I'm not sure will work here, is > list_to_existing_atom/1, At Tail-f, we use that quite a lot. Hmm, great minds think alike. :-) That's exactly how I fixed it: the code (not yet pushed) first tries list_to_existing_atom and if that fails, then just returns a string. --steve |
From: Steve V. <vi...@ie...> - 2011-04-28 04:03:03
|
On Sun, Apr 24, 2011 at 9:52 PM, Steve Vinoski <vi...@ie...> wrote: > OK, I fixed issue #50 yesterday and pushed it to github. I'm now > looking at the existing JSON-RPC support in yaws_rpc and it too calls > list_to_atom on received strings, which is a no-no. I'll need to fix > that as part of the JSON-RPC 2.0 update. More updates on this effort. Summary is that I'm making progress but hitting unexpected snags. Be aware that JSON-RPC over HTTP is just as bad as SOAP in that it's tunnelled, which is bad because HTTP is an application protocol, not a transport protocol. What this means is: * scenarios for which one would normally return meaningful HTTP status codes go out the window, replaced with 200 OK no matter what, and any error or success indications instead buried/tunnelled in the response payload * current yaws_rpc implementation of JSON-RPC is wrong because it still tries to use HTTP error codes for a variety of scenarios The end result is that fixing this will take longer than I thought. The yaws_rpc module also supports haxe and soap, so I have to try to make sure I don't break them as I fix JSON-RPC. Seeing as how there are no haxe or soap tests here, that will be interesting... --steve |
From: Steve V. <vi...@ie...> - 2011-05-02 02:35:51
|
On Thu, Apr 28, 2011 at 12:02 AM, Steve Vinoski <vi...@ie...> wrote: > On Sun, Apr 24, 2011 at 9:52 PM, Steve Vinoski <vi...@ie...> wrote: >> OK, I fixed issue #50 yesterday and pushed it to github. I'm now >> looking at the existing JSON-RPC support in yaws_rpc and it too calls >> list_to_atom on received strings, which is a no-no. I'll need to fix >> that as part of the JSON-RPC 2.0 update. > > More updates on this effort. Summary is that I'm making progress but > hitting unexpected snags. > > Be aware that JSON-RPC over HTTP is just as bad as SOAP in that it's > tunnelled, which is bad because HTTP is an application protocol, not a > transport protocol. What this means is: > > * scenarios for which one would normally return meaningful HTTP status > codes go out the window, replaced with 200 OK no matter what, and any > error or success indications instead buried/tunnelled in the response > payload > > * current yaws_rpc implementation of JSON-RPC is wrong because it > still tries to use HTTP error codes for a variety of scenarios > > The end result is that fixing this will take longer than I thought. > The yaws_rpc module also supports haxe and soap, so I have to try to > make sure I don't break them as I fix JSON-RPC. Seeing as how there > are no haxe or soap tests here, that will be interesting... OK, I just pushed all the changes required to support JSON-RPC 2.0. Please navigate over to https://github.com/klacke/yaws and give the new code a try. I believe the new code supports everything on the JSON-RPC 2.0 page at http://groups.google.com/group/json-rpc/web/json-rpc-2-0, including batch calls and notifications. --steve |