It was disheartening to learn (via Brent, via Dave) that Blogger is planning on moving away from XML-RPC in favor of SOAP:
We are moving away from XML-RPC. If you choose to take advantage of the capabilities of the new API, you will need to use SOAP instead of XML-RPC. This was a difficult decision (made collectively by the designers of Echo), because there is a lot of investment in XML-RPC in the blogging tool space, and it is great for getting things done quickly. But we felt the technical advantages offered by SOAP were worth the effort. [their emphasis]
Here's my take on what this means for Blogger developers:
- Everyone who wants to talk to the new API will have to find or write a SOAP implementation that works in the development environment they're using for their application.
- Applications will have to be adapted to call through the new interfaces using SOAP rather than XML-RPC
- Lots of interop testing will have to be done. This takes lots of time, which is expensive. I know from personal experience.
- The capabilities (and usability) of available SOAP toolkits may vary widely. Whether the limitations of various SOAP toolkits will become apparent in the (N)Echo API remains to be seen, but my past experience tells me that there's often a lot more work involved in calling APIs using SOAP than might be apparent on the surface.
- For the unfortuante developers who'll have to come up with their own SOAP implementation, there's an enormous barrier to entry, which will be especially difficult if not impossible for independent developers -- who if I understand correctly were supposed to be the very developers that the (N)Echo effort is trying to help the most.
- Users will have to upgrade their applications to the new versions. In all likelihood, there will be bugs and some users will lose data. Who will take the blame for this? The developers.
Will it be worth it? Will what we have at the end of this process be better than what we already have? I don't have a crystal ball, but my fear is that we developers will have a large amount of work to do if we want to support this decision, and that the benefit to our users will be negligable.
A few other comments...
There are four reasons cited in the (N)Echo Wiki for not using XML-RPC. I'll go through them one-by-one:
- "Serious historical confusion about whether string types supported encodings other than just ASCII."
As noted in the Wiki, this has been resolved. As best I can tell, it was a non-issue from the beginning, and as on 6/30/03 Dave updated the XML-RPC spec to clarify that XML-RPC supports any string encoding that's valid XML.
- "Doesn't support SSL. (HTTPS is not identified as a valid transport mechanism in the spec)."
Dave says in the Wiki, "if you asked me if you can use HTTPS to transport XML-RPC I would say yes. HTTPS is HTTP." See also this message on the XML-RPC discussion group.
- "Doesn't support timezones."
As I noted in my comment in the Wiki, there's no reason that this problem isn't really easy to solve. Just express dates in GMT.
- The fourth reason has been deleted from the Wiki since I started writing this. Basically it said that if the (N)Echo API were to send posts back and forth as XML, then they would have to be entity-enocded if it were to use XML-RPC, and that this isn't an issue with SOAP.
I don't think the reasoning here is totally sound, which is probably why it was removed from the page. If SOAP is used for passing posts back and forth as XML, then they'd still have to be encoded. As I recall, SOAP does have a provision for transporting XML documents, but I'd venture to guess that support for this feature is not available in many of the current implementations, and even then, there are probably huge interop issues looming, since it's one of the more advanced features of the SOAP specification.
Evan cites Ben Trott's "Why we need Echo" reasoning for not using XML-RPC. Ben has updated the page since it was originally posted, with a note that the internationalization issue has been resolved -- basically the same resolution now listed in the Wiki's first reason for not using XML-RPC. As far as I can tell, this is Evan's only reason for using SOAP over XML-RPC, and it's a red herring.
Lastly, Evan notes parenthetically that the decision to use SOAP over XML-RPC was "made collectively by the designers of Echo". As far as I can tell, no such consensus has yet been reached, and SOAP isn't even the only alternative to XML-RPC. To say now that Blogger will favor SOAP over XML-RPC is at least jumping the gun.
I wonder what other motivations are behind this statement. We know that Google has SOAP server-side tools, since the GoogleAPI uses SOAP. I wouldn't be surprised to learn that Google's engineers have done a lot of fine-tuning on their SOAP implementation. Could this have had any influence on Blogger's decision to move to SOAP?
14:17'36 
|
|
