John Burkhardt on the SOAP-header issue I stumbled on trying to let Radio use Groove Web Services. Simon Fell describes the problem in some more detail. Dave Winer argues that Radio's SOAP-stack is BDG-compliant, and new applications should be backward compatible.  Which in this case would mean: SOAP-Headers are not in the BDG so Groove should adapt and drop the headers? Hmm, I'm not very interested in questions like this, I just want something that works. All I'm saying is:  I can't add a SOAP header when using Radio's builtin SOAP-client: soap.rpc.client. Radio's soap.rpc.client function can only add the SOAP-Body apparently. Groove needs a SOAP-header for security reasons and as Sam Ruby points out, SOAP-headers are around for some years now. Ok, Radio is BDG-compliant - clear - but then soap.rpc.client has to be dropped for interop with Groove. So...I understand Dave Winer's point that new apps should be compatible with older apps, but Groove also scores points when wanting to move foreward using the specs of today. Bottomline: too bad I can't use Radio's SOAP-client!

Which on the other hand is rather fun , because now I got the chance to write a sort-of Radio SOAP-client which can send the disputed header. Whether this is real interop is a theoretical question, but i'm pretty sure it works. 200 OK?!

tons o' fun

Writing this from a Groove Discussion Tool. A Radio Userland Tool scans the discussion for new/edited entries. When found the tool grabs the entry and publishes it thru Radio... try some editing.... and some more...

Got the Groove/Radio Interop going, but it wasn't that easy. Lyrical as I am about Radio's scripting capabilities, i'm sad to say that Radio's builtin SOAP-client, can't send any SOAP-headers. This means one cannot use Radio's SOAP-client to connect to Groove. So... then I tried sending my SOAP using Radio's tcp.httpClient. Only to find out that Radio's webserver is a HTTP/1.0 server and Groove: yes you guessed right: HTTP/1.1. Won't work either! Grrrr! Luckily Radio has a function rpc.openstream() and....YES!!! That works!Bit of disadvantage is that one has to create the HTTP-header and SOAP-message by hand.

So... Dave: HTTP/1.1 + SOAP-headers? Please? ;-)

A Radio Userland tool connects to Groove using Groove Web Services and retreives files from a Groove Files Tool:

<%grooveInteropSuite.html.listFiles()%>
After retreiving the files are copied to RU's www-folder, and voila: the 'private' Groove files are now published to the web.

Macromedia's Flash MX beta version from version 6,0,60,48 and up support the customization of HTTP request headers !!!:

• myXML.addRequestHeader("SOAPAction", "\"/radio\"");


• myXML.sendAndLoad( "http://localhost:5335/radio", myResponseXML);

This means one can send a SOAP message to for example Radio...

Wow! After installing Radio Userland long. long time ago, neglected RU's scripting capabilities since. I knew it was good stuff, but this good....Last week I took a better look, and discovered incredible ease of use (if one knows a little scripting). Creating a new Radio Tool is just one mouseclick away! Thanks Dave, soon there will be the Groove Interop Tool for Radio!

Decided to look at Radio because release of Groove 2.5 is not long away. Point is: Radio is a SOAP server/client and so is Groove 2.5! Groove will function as your own private webserver, much like RU. All kinds of fun things will be possible:

• Notify Groove that RU recieved fresh hot news


• Notify Groove a post was added to/deleted from RU


• Add/Edit posts from Groove (Collabborative blogging!)


• Subscribe to news from Groove


• etc.