Hi All,
I have just been testing xmlrpc on some of the IMS module RPC functions and got some errors using nested structures. viz "{". Having a quick look through the xmlrpc code show that it doesn't support nested structures in the reply.
I am quite happy to fix this but am surprised that nobody has mentioned this before as I see there are a few modules that use nested replies. Does this maybe mean that XMLRPC is going to be deprecated (not a usual module)?
Cheers Jason
Hello,
xmrpc is not going to be deprecated, it is actually the newer one.
But it is implementation from scratch, no external xmlrpc being used. So far it was implemented as much as it was needed. However, nested structures in replies should be supported. What is exactly the error you get? If there is an issue, it has to be fixed.
I just tested 'sercmd ul.dump' and worked fine, returning:
{ Domain: location Size: 512 AoRs: { AoR: 401 HashID: 3325474 Contacts: { Contact: { Address: sip:401@192.168.178.22:1024;line=1uxhrhwy Expires: 3541 Q: 0.000000 Call-ID: 3c267033369e-d3i5csinl2h7 CSeq: 6300 User-Agent: snom370/8.4.35 Received: [not set] Path: [not set] State: CS_NEW Flags: 0 CFlags: 0 Socket: udp:192.168.178.21:5060 Methods: 6111 Ruid: uloc-4fb17657-71d-1 Instance: urn:uuid:3d1a0962-4751-426f-8492-0004132672E3 Reg-Id: 1 } } } Stats: { Records: 1 Max-Slots: 1 } }
It has lot of inner structures.
Cheers, Daniel
On 5/14/12 5:14 PM, Jason Penton wrote:
Hi All,
I have just been testing xmlrpc on some of the IMS module RPC functions and got some errors using nested structures. viz "{". Having a quick look through the xmlrpc code show that it doesn't support nested structures in the reply.
I am quite happy to fix this but am surprised that nobody has mentioned this before as I see there are a few modules that use nested replies. Does this maybe mean that XMLRPC is going to be deprecated (not a usual module)?
Cheers Jason
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hi Daniel,
Yes, the RPC API does support nested struct, but at first glance the XMLRPC doesn't. The sercmd test you did will work so long as you use named pipe transport. If you try and do a ul.dump using XMLRPC you will get an error on the nested structure fmt "{". I will have a look at it today and let you know.
Cheers Jason
On Mon, May 14, 2012 at 11:20 PM, Daniel-Constantin Mierla < miconda@gmail.com> wrote:
Hello,
xmrpc is not going to be deprecated, it is actually the newer one.
But it is implementation from scratch, no external xmlrpc being used. So far it was implemented as much as it was needed. However, nested structures in replies should be supported. What is exactly the error you get? If there is an issue, it has to be fixed.
I just tested 'sercmd ul.dump' and worked fine, returning:
{ Domain: location Size: 512 AoRs: { AoR: 401 HashID: 3325474 Contacts: { Contact: { Address: sip:401@192.168.178.22:1024;line=1uxhrhwy Expires: 3541 Q: 0.000000 Call-ID: 3c267033369e-d3i5csinl2h7 CSeq: 6300 User-Agent: snom370/8.4.35 Received: [not set] Path: [not set] State: CS_NEW Flags: 0 CFlags: 0 Socket: udp:192.168.178.21:5060 Methods: 6111 Ruid: uloc-4fb17657-71d-1 Instance: urn:uuid:3d1a0962-4751-426f-8492-0004132672E3 Reg-Id: 1 } } } Stats: { Records: 1 Max-Slots: 1 } }
It has lot of inner structures.
Cheers, Daniel
On 5/14/12 5:14 PM, Jason Penton wrote:
Hi All,
I have just been testing xmlrpc on some of the IMS module RPC functions and got some errors using nested structures. viz "{". Having a quick look through the xmlrpc code show that it doesn't support nested structures in the reply.
I am quite happy to fix this but am surprised that nobody has mentioned this before as I see there are a few modules that use nested replies. Does this maybe mean that XMLRPC is going to be deprecated (not a usual module)?
Cheers Jason
sr-dev mailing listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda