It’s just data

Groove, Radio, and Leaky Abstractions

Tim KnipGroove 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.

Rick Olson: I had the same issue trying to get the Muse.Net client to work. It was a little more difficult to use the lower level Radio methods to send headers, but I just wrapped it up in my own wrapper and all was good.

Unquestionably, functions like soap.rpc.client provide value, but abstractions fail.  When they do isn't it nice to know that you can drop down to a lower level interface when necessary?


Sam, you can definitely drop down to a lower level. Our SOAP support is entireley implemented in scripts, and full source is provided.

Posted by Dave Winer at

Not only can you, but apparently Tim did. Ain't SOAP great? ;-)

Posted by Sam Ruby at

Yup, not only did Tim pull it off, but he built some incredibly cool tools to integrate Groove with Radio. In general he had a pretty good experience too! He was loving the fact that he could still do what he wanted to with Radio's scripting system. The whole thing is proof positive that SOAP and XML are easily malleable and flexible. And I think its perfectly reasonable and even expected that we put a little shim here and there when we need to.

Posted by John Burkhardt at

That's why I like Radio, one *can* drop to a lower level to get things done.

Posted by Tim Knip at

Add your comment