Re: Larger than 32bit signed?

>I would accept the need for change if there turned out
>to exist some functionality that cannot be expressed
>with the existing data types of XML-RPC.

What do you see as the purpose of XML-RPC, then?  With just plain HTTP
(indeed with just plain IP), you can express all the things people want
to express with XML-RPC extensions.  So why go to the trouble of defining
XML element types such as <int>?

I think it has to do with making programming easier and making specification
of a particular client/server interface easier.  Both of those causes are
advanced by adding new data types as opposed to tunneling specific types
of data over <string>.

>it's a small price to be paid for the benefit of universal
>interoperability.

Does anyone have examples of the interoperability we're trying to
preserve by sticking to a standard?  It's not the case that any
XML-RPC client can talk to any XML-RPC server.  They both have to be
using the same method set.  Those methods are implemented, on each
side, by a software package.  Since you have to get a proper package
of software to do the foo.bar method, how much more trouble is it to
get a package of software that knows XML-RPC Version X?

This is in contrast to the World Wide Web situation, where the HTML
standard means a single browser program can display the contents of
any web page.

My personal use of XML-RPC is entirely in private communications -- I
own the client and server and use the same XML-RPC layer software
package on both.  So I don't have a clear view of the interoperability
requirements.

-- 
Bryan Henderson                                    Phone 408-621-2000
San Jose, California


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/xml-rpc/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/