RE: how bad is soap?

["Ayyasamy, Senthilkumar (UMKC-Student)" <saq66@umkc.edu>]

>Andy> Examples of protocol message exchanges are also helpful to
>Andy> vendors and operators in determining the cost/benefit ratio
>Andy> of the proposal. 
>
>Your reasoning is based on the obvious technical low-level costs as
>"bytes in the message per netconf operation" or "kbytes for a netconf
>implementation" or "cpu cycles to process a message". This is a good
>reasoning, that I acknowledge. To this reasoning SOAP (as well as XML)
>would not be a wise solution.

yes. All this arguments are not just for XML-RPC or SOAP, but it is
common for any XML based service. XML has lot of on the fly 
compression techniques like Xmill etc (but, depends on the exact
benefits from the compression time Vs throughput.)

But, SOAP and WSDL adds some more complexity- as it is *software+data*
as service. A lot more factors have to be considered for a fast 
response time at the time of issuing a request, getting the
reply, likelihood of issuing future requests etc. 


I myself think doing WSDL + SOAP way will be much more easy. A lot of
tools and support are available. But, till we have an alternate 
proposal on the table, its better to see the issues around enns
draft (rather than discussing relative benefits of XML-RPC Vs other 
protocols.)

After, we have both the implementations ( which is an very easy
work -- atleast WSDL+SOAP way.), we can examine them more from
performance perspective. I can volunteer for such an examination.
For now, have a look at examination of complexities around 
XML-RPC by mark.

http://roland.grc.nasa.gov/~mallman/research/proj-xmlrpc.html






--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>