[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: XMLConf RPC



Title: RE: XMLConf RPC

Hi Phil,

Thanks for the insight. Here are a couple of comments:

To transport XML data in XML/RPC, there is the String data type,
which of course means that you have to encode < and &
as &lt and &amp (like any other data in an XML document).
This, however, has the effect of clearly separating
the RPC mechanism from the RPC data (parameter values and return values).
The proposed RPC actually mixes the RPC tags with tags of
the data (if the data is an XML document itself). This is
inconsistent with the treatment of non-xml data since sometimes
my data integrates as mark-up with the RPC mark-up, and
sometimes it doesn't. I'm not sure I would refer to this
as generic. Convenient in certain cases maybe, but not
really generic.

Also, the lack of data types in the proposed mechanism
is likely to be regrettable down the road. While someone
can always encode data types manually in the payload, it
would be nice if they were defined in the standard.

I'm not lobbying for XML/RPC specifically, however, I think
that a more generic (and standard) mechanism for performing
the RPC is necessary. XML/RPC just seemed like a nice lightweight
mechanism to do this. I suppose with the general trend
of web services moving towards SOAP, SOAP may in fact be
the logical path for XMLConf RPC.

Thanks,

Bryan


-----Original Message-----
From: Phil Shafer [mailto:phil@juniper.net]
Sent: Monday, March 24, 2003 4:30 PM
To: Strickland, Bryan [NCRTP:4133:EXCH]
Cc: xmlconf@ops.ietf.org
Subject: Re: XMLConf RPC


"Bryan Strickland" writes:
>Has XML/RPC been considered as an RPC mechanism for XMLConf?

XMLRPC does not give a generic mechanism for transporting XML. It also mixes schema and data:

   <array>
     <data>
      <value><i4>12</i4></value>
      <value><string>Egypt</string></value>
      <value><boolean>0</boolean></value>
      <value><i4>-31</i4></value>
    </data>
   </array>

We didn't see at as a good match for our needs.

Thanks,
 Phil