Comments on: XML-RPC, a mini case study http://decafbad.com/blog/2002/11/26/oooccb It's all spinning wheels and self-doubt until the first pot of coffee. Fri, 10 Oct 2008 19:53:20 +0000 http://wordpress.org/?v=2.7-hemorrhage hourly 1 By: 0xDECAFBAD » Greatest Hits Vol. 1, the Tinkery Bits http://decafbad.com/blog/2002/11/26/oooccb#comment-348864 0xDECAFBAD » Greatest Hits Vol. 1, the Tinkery Bits Sat, 26 Apr 2008 21:05:36 +0000 http://www.decafbad.com/blog/?p=307#comment-348864 <p>[...] Nov 26: XML-RPC, a mini case study Wherein I talk about how XML-RPC has worked for [...]</p> [...] Nov 26: XML-RPC, a mini case study Wherein I talk about how XML-RPC has worked for [...]

]]> By: Joh http://decafbad.com/blog/2002/11/26/oooccb#comment-475 Joh Tue, 30 Nov 1999 00:00:00 +0000 http://www.decafbad.com/blog/?p=307#comment-475 <p>...unless your client is in China and oops, Dave forgot to mention that since Radio can't do Unicode, the XmlRpc spec only uses ASCII strings. (also oops for Russia, Africa, Arabia (ok, you guys gonna throw bombs at them anyway) and all others who sometimes use non-american characters).</p> <p>Damn, then.</p> <p>That's why non-american companies tend to use SOAP. If XmlRpc (and most implementations) would not unnecessarily exclude 2+ byte characters, which have been specified in the XML-spec (XML is Unicode) by the way, it would be fine. I can't sell an API for hotels in a country where my software can't spell the name of a customer... "does your name have an english spelling, sir?"</p> …unless your client is in China and oops, Dave forgot to mention that since Radio can’t do Unicode, the XmlRpc spec only uses ASCII strings. (also oops for Russia, Africa, Arabia (ok, you guys gonna throw bombs at them anyway) and all others who sometimes use non-american characters).

Damn, then.

That’s why non-american companies tend to use SOAP. If XmlRpc (and most implementations) would not unnecessarily exclude 2+ byte characters, which have been specified in the XML-spec (XML is Unicode) by the way, it would be fine. I can’t sell an API for hotels in a country where my software can’t spell the name of a customer… “does your name have an english spelling, sir?”

]]> By: John Burton http://decafbad.com/blog/2002/11/26/oooccb#comment-476 John Burton Tue, 30 Nov 1999 00:00:00 +0000 http://www.decafbad.com/blog/?p=307#comment-476 <p>Well you can just go ahead and use XmlRpc and UTF-8 encode your unicode strings. Which might be a technical violation of the spec but seems to work well enough in practice.</p> <p>Or encode strings as int arrays containing unicode characters?</p> Well you can just go ahead and use XmlRpc and UTF-8 encode your unicode strings. Which might be a technical violation of the spec but seems to work well enough in practice.

Or encode strings as int arrays containing unicode characters?

]]> By: John Burton http://decafbad.com/blog/2002/11/26/oooccb#comment-477 John Burton Tue, 30 Nov 1999 00:00:00 +0000 http://www.decafbad.com/blog/?p=307#comment-477 <p>I'd like to build XmlRpc server functionallity into an application we have, but can't find a c++ server library that works under windows (as opposed to unix). Does anyone know of one, or will I have to do it miyself it I want this?</p> I’d like to build XmlRpc server functionallity into an application we have, but can’t find a c++ server library that works under windows (as opposed to unix). Does anyone know of one, or will I have to do it miyself it I want this?

]]> By: Paul Prescod http://decafbad.com/blog/2002/11/26/oooccb#comment-478 Paul Prescod Tue, 30 Nov 1999 00:00:00 +0000 http://www.decafbad.com/blog/?p=307#comment-478 <p>I've posted some thoughts: http://www.blogstream.com/pauls/1038403139</p> I’ve posted some thoughts: http://www.blogstream.com/pauls/1038403139

]]> By: l.m.orchard http://decafbad.com/blog/2002/11/26/oooccb#comment-479 l.m.orchard Tue, 30 Nov 1999 00:00:00 +0000 http://www.decafbad.com/blog/?p=307#comment-479 <p>I was about to say that the Unicode issue hasn't been one for us, because we don't really have anything for human consumption in our APIs. That is, no presentation strings or words or sentences.</p> <p>But then I had to think about that - we do simple shared sign-up & login via XML-RPC. If we had to do such a promotion globally, we might have problems with login names and passwords.</p> <p>I'm sure there're more landmines awaiting my feet.</p> I was about to say that the Unicode issue hasn’t been one for us, because we don’t really have anything for human consumption in our APIs. That is, no presentation strings or words or sentences.

But then I had to think about that - we do simple shared sign-up & login via XML-RPC. If we had to do such a promotion globally, we might have problems with login names and passwords.

I’m sure there’re more landmines awaiting my feet.

]]> By: Taisuke Yamada http://decafbad.com/blog/2002/11/26/oooccb#comment-480 Taisuke Yamada Tue, 30 Nov 1999 00:00:00 +0000 http://www.decafbad.com/blog/?p=307#comment-480 <p>While Unicode in XML-RPC is surely an issue of original specification, that is not a practical one as most implementations never bother to enforce that limitation (why limit it when underlying XML processor allows _any_ charset encoding?).</p> <p>Now, regarding REST and XML-RPC, I too agree that Dave's comment on REST was bit off. OTOH, I think I can understand why he sees XML-RPC based design is more appropriate (for his goal) than REST-style design.</p> <p>While REST focuses on defining set of accessible resources, XML-RPC focuses on defining set of callable interfaces.</p> <p>Traditional programming is about "programming by contract", and in many languages, that means defining set of interfaces (API). Many developers are just so much trained to have this API-centric world view, and adopting REST means there's a need to tweak their heads a little.</p> <p>I think it could be argued that this use of "set of resources" is almost same as using multiple objects in OO language. Whole service is constructed by interaction of multiple live objects (resources), and each object (resource) has set of interfaces to be called. I believe REST principle requires you to break up service into smaller set of objects until eash object only needs to implement minimal set of standard interface. But what's puzzling me right now is the way to "expose" selected micro-objects as URI-addressable resource. This is probably more of a problem of toolkit implementation, but it's currently just awkward to me.</p> <p>Unless RESTful implementation brings easy way to do it, XML-RPC will be understood <em>much</em> faster by developers than REST-style programming model. I'm wondering if this is going to be a typical "worse-is-better" case.</p> While Unicode in XML-RPC is surely an issue of original specification, that is not a practical one as most implementations never bother to enforce that limitation (why limit it when underlying XML processor allows _any_ charset encoding?).

Now, regarding REST and XML-RPC, I too agree that Dave’s comment on REST was bit off. OTOH, I think I can understand why he sees XML-RPC based design is more appropriate (for his goal) than REST-style design.

While REST focuses on defining set of accessible resources, XML-RPC focuses on defining set of callable interfaces.

Traditional programming is about “programming by contract”, and in many languages, that means defining set of interfaces (API). Many developers are just so much trained to have this API-centric world view, and adopting REST means there’s a need to tweak their heads a little.

I think it could be argued that this use of “set of resources” is almost same as using multiple objects in OO language. Whole service is constructed by interaction of multiple live objects (resources), and each object (resource) has set of interfaces to be called. I believe REST principle requires you to break up service into smaller set of objects until eash object only needs to implement minimal set of standard interface. But what’s puzzling me right now is the way to “expose” selected micro-objects as URI-addressable resource. This is probably more of a problem of toolkit implementation, but it’s currently just awkward to me.

Unless RESTful implementation brings easy way to do it, XML-RPC will be understood much faster by developers than REST-style programming model. I’m wondering if this is going to be a typical “worse-is-better” case.

]]> By: l.m.orchard http://decafbad.com/blog/2002/11/26/oooccb#comment-481 l.m.orchard Tue, 30 Nov 1999 00:00:00 +0000 http://www.decafbad.com/blog/?p=307#comment-481 <p><strong>Please fix the XML-RPC spec</strong></p> <p>I've written before that I love XML-RPC, and that it has served me well in the past couple of years. I think it's the right tool for a broad range of jobs. But, after having studied the spec, and after having implemented it in a handful of language</p> Please fix the XML-RPC spec

I’ve written before that I love XML-RPC, and that it has served me well in the past couple of years. I think it’s the right tool for a broad range of jobs. But, after having studied the spec, and after having implemented it in a handful of language

]]> By: l.m.orchard http://decafbad.com/blog/2002/11/26/oooccb#comment-482 l.m.orchard Tue, 30 Nov 1999 00:00:00 +0000 http://www.decafbad.com/blog/?p=307#comment-482 <p><strong>Please fix the XML-RPC spec</strong></p> <p>I've written before that I love XML-RPC, and that it has served me well in the past couple of years. I think it's the right tool for a broad range of jobs. But, after having studied the spec, and after having implemented it in a handful of language</p> Please fix the XML-RPC spec

I’ve written before that I love XML-RPC, and that it has served me well in the past couple of years. I think it’s the right tool for a broad range of jobs. But, after having studied the spec, and after having implemented it in a handful of language

]]> By: l.m.orchard http://decafbad.com/blog/2002/11/26/oooccb#comment-483 l.m.orchard Tue, 30 Nov 1999 00:00:00 +0000 http://www.decafbad.com/blog/?p=307#comment-483 <p><strong>Please fix the XML-RPC spec</strong></p> <p>I've written before that I love XML-RPC, and that it has served me well in the past couple of years. I think it's the right tool for a broad range of jobs. But, after having studied the spec, and after having implemented it in a handful of language</p> Please fix the XML-RPC spec

I’ve written before that I love XML-RPC, and that it has served me well in the past couple of years. I think it’s the right tool for a broad range of jobs. But, after having studied the spec, and after having implemented it in a handful of language

]]> By: l.m.orchard http://decafbad.com/blog/2002/11/26/oooccb#comment-484 l.m.orchard Tue, 30 Nov 1999 00:00:00 +0000 http://www.decafbad.com/blog/?p=307#comment-484 <p><strong>Please fix the XML-RPC spec</strong></p> <p>I've written before that I love XML-RPC, and that it has served me well in the past couple of years. I think it's the right tool for a broad range of jobs. But, after having studied the spec, and after having implemented it in a handful of language</p> Please fix the XML-RPC spec

I’ve written before that I love XML-RPC, and that it has served me well in the past couple of years. I think it’s the right tool for a broad range of jobs. But, after having studied the spec, and after having implemented it in a handful of language

]]>