Re: Larger than 32bit signed?
Aleksandar Janicijevic <[email protected]>
| Newsgroups | gmane.text.xml.rpc.specification |
|---|---|
| Message-ID | <[email protected]> |
> 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>?
Indeed, you could implement everything over HTTP (just
like they do in REST, right?), or using TCP sockets,
or certainly in many other ways. Well, maybe this is
just my opinion, but I think the advantage of XML-RPC
is simplicity and universal availability. I mean, you
can easily make a server or client in any language on
any platform, and the fact that it is XML-RPC helps
you to guarantee that you can talk to the other side.
For example, HTTP is probably universally available as
well, but if you want to use HTTP for remote procedure
call, you have to define data formats that both sides
have to observe and everything that is already defined
in XML-RPC.
>
> 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>.
I suppose you are right, my main concern is just that
this process of extension in practice so easily gets
out of hand. Other than those middleware examples, one
extreme example that immediately comes to my mind is
C++ - it has undergone so much change (precisely
because as a language it has been so successful) that
if you want to use some advanced features you first
have to make sure that you version of compiler
supports them at all. If we could somehow produce a
new standard that would have some level of stability,
then I don't see anything wrong in doing that.
>
> 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.
>
Well if you control both sides, then you don't really
care. In that case you can extend the format to your
hart's content. But imagine that Google provides
search service through some specific version of
XML-RPC, then in order to use it you have to
accommodate your client code to that service. And even
worse, imagine that your client has to talk to two
different services, and each of them uses a slightly
different version of the standard. That would be bad.
Aleksandar
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/