Archive of UserLand's first discussion group, started October 5, 1998.

Is XML-RPC a scripting environment?

Author:Dave Winer
Posted:1/20/1999; 4:35:39 AM
Topic:Frontier on MacOS X Server
Msg #:2293 (In response to 2292)
Prev/Next:2292 / 2294

This raises an interesting question that can only be raised by gluing together diverse environments like Python, Perl and Frontier. I'm so glad we're doing this, it's an incredible way to learn about other systems, quickly.

The question comes down to this -- is XML-RPC itself a scripting environment? If so, we have to address questions like this. And if so we must take a least-common-denominator approach. If Perl doesn't have a boolean type, perhaps we shouldn't have a boolean type in the common language? If one language doesn't easily coerce an integer into a double then it's not cool for one XML-RPC implementation to do that automatically. This came home to me when the issue of an being sent across the wire as 2.0 came up. Frontier would never do that. But I could easily imagine that BASIC would.

Another possible view is that XML-RPC is *not* a scripting environment, and therefore shouldn't define coercions, and leave it up to each server writer to explain the behavior of his or her server. Example: "My server won't care if you send me an with a value of 2.0, or even 2.01902 (it'll do the truncation automatically)."

My own opinion, at this moment, is that we should try for the first approach, to get a rigorous set of rules in place about what coercions will take place. We can make Perl better by including booleans in the wire protocol, clearly Perl must have *some* convention for what a boolean is, right? How could you program without booleans? So if the language doesn't have support for boolean, we could simply say when Perl gets a true it is always turned into a 1 and a false is always 0.

There are responses to this message:

This page was archived on 6/13/2001; 4:47:25 PM.

© Copyright 1998-2001 UserLand Software, Inc.