| About InfoWorld : Advertise : Subscribe : Contact Us : Awards : Events : Store |
 |
||||
|
||||
 |
||||
 |
|
|||
 |
||||
|
|
|
||
|
|||||||||||||||||||||||||||||||||||||||
 COLUMN
Script locally, publish globally InfoWorld Test Center Director Steve Gillmor and I have always thought that Groove is the tool we ought to be using to coordinate our team's ongoing mind-meld, aka the InfoWorld editorial process. It hasn't worked out that way, though. I used to blame that on Steve, who has little use for communication that doesn't show up as text (in the body, *not* an attachment!) of e-mail messages delivered to his BlackBerry.
Groove itself is, of course, a bundle of really useful services: secure shared spaces, ad-hoc group formation within or across corporate borders, instant messaging and presence, reliable data synchronization, and graceful support for offline or firewalled endpoints. For the longest time, we've envisioned using Groove to collect key sources of information, create and discuss work-in-progress, and transmit results through various channels. Unfortunately the Groove developer's kit focuses heavily on creating tools that plug in to the Groove transceiver. That is a craft with few masters, and after a long frustrating day trying to get to "Hello, world" I realized I am not destined to be one of them. A few months back, I participated in an online experiment with a bunch of Groove developers. The idea was to explore synergies between the private world of Groove shared spaces and the public world of Weblogs. One of the developers, Hugh Pyle, injected into our space a Groove tool he'd written that subscribes to RSS channels and displays their (linked) headlines. This was different from my normal experience of reading RSS channels -- and it was different in exactly the way that defines Groove. Management of the list of subscribed channels and awareness of the information flowing through them was a team process. The source code for the tool wasn't available, though, and re-creating it wasn't going to be easy. Things that I could do in my sleep, using an Internet-aware scripting language like Perl or Python, were really hard to accomplish using the GDK. Fast-forward to Thanksgiving weekend. I'd sworn to stay off the computer, but when the Groove 2.5 beta CD with the GWS bits landed on my doorstep, I couldn't resist. There were two GWS demos included. One is a .Net WinForms app written in C#. It uses the GWS SOAP APIs to traverse your identities, their shared spaces, (some of) the tools in those spaces, and the data belonging to the tools. Then it dumps everything into a navigable tree control. The other app was, to my delight, a Perl script that uses SOAP::Lite and some GWS-encapsulating Perl glue to perform command-line traversal and also editing. You can use it, for example, to enumerate and fetch files stored in a shared repository (Files tool), or create and edit messages in a forum (Discussion tool). I haven't been playing with GWS for long, but progress so far is encouraging. I've written C# and Perl versions of an agent that monitors a Groove discussion forum, watching for references to URLs. When it sees a message containing an URL, it fetches that Web page and stores it in a Files repository. Then it updates the message, in situ, to indicate that the referenced page was retrieved and is stored locally. "Local" is a funny word in this context, though. The C# and Perl programs talk to a local SOAP listener which mediates access to the Groove engine. But of course, as soon as a file is stored in the repository belonging to my instance of the shared space, it synchronizes to yours too. Script locally, publish globally. Except, of course, this isn't global; the scope is precisely the virtual team invited into the space. None of this will make Steve happy, mind you. He'll want to be notified on his BlackBerry when an item of interest is added to the repository. What's more, he'll want to be able to e-mail a message into the discussion forum and have its arrival trigger the fetching of a file into the archive. I haven't done these things yet. But I am 100 percent certain that I can, pretty easily, because, as I said, I script that kind of stuff in my sleep. A few columns ago I wrote: "Real business process integration will mean deploying a mixture of heavy, medium, and lightweight services in the cloud, on the intranet, and even (in peer-to-peer mode) on the desktop. Modern scripting languages, the duct tape of the Internet, are SOAP-capable and stand ready to deliver." [2] Enterprises are held together by scripting, in ways that we sometimes don't like to admit. But there's no shame in it. Wear your duct tape proudly. It's getting more useful all the time. 1. http://www.infoworld.com/articles/pl/xml/02/11/04/021104plgroove.xml 2. http://www.infoworld.com/articles/op/xml/02/09/26/020926opwebserv.xml Jon Udell is lead analyst at the InfoWorld Test Center. Contact him at jon_udell@infoworld.com and check out his Weblog at http://weblog.infoworld.com/udell.  RELATED SUBJECTS  Web TechnologiesSPONSORED WHITE PAPERS 
SPONSORED LINKS
|
|||||||||||||||||||||||||||||||||||||||
|
||||||||||
|
||||||||||
