XML-RPC vs. RTC Format

25.10.2006 11:49:37
Registered user

There are two major differences between the XML-RPC format and the RTC format.
One difference is that XML-RPC doesn‘t support all types supported by RTC, so multiple RTC types need to be mapped to a single XML-RPC type. Because of this, some type information will be "lost" when sending the data over XML-RPC. Here is a list showing how your RTC types will be mapped to XML-RPC when sending the data out ...
1) rtc_Float, rtc_Currency -> <double>
2) rtc_Integer, rtc_LargeInt -> <int>
3) rtc_Text, rtc_String, rtc_WideString, rtc_Variable -> <value>
4) rtc_DateTime -> <datetime.iso8601> (no miliseconds)
5) rtc_Boolean -> <boolean>
6) rtc_DataSet -> <struct> with "Fields" and "Rows" as <array>s
7) rtc_Exception -> <fault><struct>
8) rtc_Record -> <struct>
9) rtc_Array -> <array>
10) rtc_ByteStream -> <base64>
11) rtc_Null -> <nil/>
When RTC Clients need to talk to a RTC Server (and vice-versa), you can send all RTC types like DataSets and Exceptions as parameters and all other XML-RPC apps will be able to decipher the data, but other XML-RPC apps will most likely see the data "differently".
For example, a rtc_DataSet will be seen as a <struct> with two <array>s and not as a single DataSet object (like in RTC SDK), while Exceptions included in other data will be seen as a <struct> with 2 <member>s (unless it‘s a single Exception sent from the Server to the Client, for which the standard <fault> structure will be used).
You can also activate both data formats on the ServerModule (fmt_RTC and fmt_XMLRPC), so your RTC clients can use the compact RTC format while other apps use XML-RPC.
Another difference is that XML-RPC function call parameters are sent in a list, where order is important, but no names are assigned, while RTC uses names for all parameters. To make the communication between RTC Clients and Servers compatible even when using XML-RPC, all parameters will be packed into a <struct>, unless you pack them in an array called "params". That way, name information will be preserved if you use the "standard RTC way", and ... if you need to talk to a server/client which wants the parameters in a list, you will pack them into an array named "params", with the first parameter at index 0.
So, if a non-RTC app will want to call a remote function written with RTC by using names, it will have to send all parameters as a single <struct> param. On the other hand, when you want to call remote functions written by other servers, unless they use the same <struct> method, you will need to pack the data in an array called "params" (elements start from index 0).
That way we are keeping 100% compatibility between RTC clients and servers, while still making communication with other XML-RPC apps possible, regardless of their format.
Best Regards,
Danijel Tkalcec

25.10.2006 12:33:46
Registered user

Here is how XML-RPC types will be mappet to RTC types when you receive a request or a response over XML-RPC ...
1) <FAULT> -> rtc_Exception
2) <METHODCALL>, <CALL> -> rtc_Function
3) <I4>, <INT> -> rtc_LargeInt
4) <BOOLEAN> -> rtc_Boolean
5) <VALUE>, <STRING> -> rtc_String
6) <DOUBLE> -> rtc_Float
7) <DATETIME.ISO8601>, <DATETIME>, <TIMESTAMP> -> rtc_DateTime
8) <BASE64>, <BASE64BINARY>, <BINARY> -> rtc_ByteStream
9) <STRUCT> -> rtc_Record; Except if it is the first and the only parameter in a function call list, in which case all values will be prepared as named parameters, "the standard RTC way".
10) <ARRAY> -> rtc_Array
11) </NIL> -> rtc_Null
Best Regards,
Danijel Tkalcec