Slashdot Mirror

http://www.soapware.org/directory/4/services/googl eApi/implementations

At the time of posting languages catered for were for AppleScript, Frontier/Radio, Perl, Python and Visual Basic. I've written a basic implementation in PHP which has yet to be added to the list - you can find it here:

http://toys.incutio.com/php/php-google-web-api.htm l

This is a very cool toy.

intro, guide, and more.

A Busy Developer's Guide to SOAP 1.1

XML-RPC was the first succesful open standard for an XML-based RPC and SOAP was based on XML-RPC. There are a number of reasons they are interesting technologies. Perhaps the biggest right now is that SOAP is one of open standard technologies at the core of Web Services and Microsoft's .NET.

Love it or hate it, there is a good chance that there will be a lot of .NET software out there Real Soon Now [tm] and it will be using SOAP as its fundamental RPC protocol. If you are a developer, then now is a good time to learn this technology.

One of the disadvantages of XML-RPC and SOAP in commercial software development is that they are very human-readable: they pass XML documents between systems. Many times this is a good thing, of course, especially when you are debugging your system. But if you are passing confidential information (say your customer's bank records) then you will need to work at obfuscating (and de-obfuscating) the XML that is actually sent.

There are also some overhead concerns with (particularly) SOAP, but careful design and use can overcome these.

However, if we can also link up diverse scripting environments with SOAP and XML-RPC, there's no reason to worry. Choice is key. Most non-Microsoft scripting languages will never run well inside Microsoft's environment. Make it easy for Perl programmers to participate in SOAP networks without leaving home. Same with Java, Python, Tcl, and everything else.

Focus on the protocols, that's what's important. As long as we invest in diversity, Microsoft can't control. Instead of a one-party-system, let's have an n-party-system. That's how we guarantee choice, eliminate lock-in, and maintain forward motion.

BTW, an interesting detail came out at the open source summit on Tuesday. Dick Hardt of ActiveState reports that Perl does not run well in Microsoft's environment. The problem is that Microsoft's virtual machine is designed to run C-like code, but Perl is not like that.

Now I know the solution, we need a DLL-based open scripting architecture, that allows environments to compile and run scripts and have them call back into the environment, much like the architecture we developed on the Mac in the early 90s. Back then it wasn't so interesting because scripting was still pretty small, it was just us and Apple. Ten years later there's been an explosion, and there's another way, beyond XML-RPC, that's needed to integrate. It can be a tough sell to each individual community, as XML-RPC is, because the benefit is that it makes it easy to bridge to other environments. Most communities tend not to see too well outside their borders. But the larger world wants choice. No matter how great your scripting environment, you will eventually meet someone you want to work with who works in a different environment.

Re constructive, he did come up w/ a response he calls "A Busy Developer's Guide to SOAP 1.1" The focus is on a SOAP subset for easy interoperation.

Umm, this post is somewhat at odds with what I understood SOAP to be. Isn't it an open standard? There's a spec here, and it certainly doesn't appear to be 'single vendor' as you put it (see here)
Q: Am I seriously missing something here?