Two more Rotterdam-triggered things, contextless. Brazil ("This is Central Services..."). And Worse Is Better ("the New Jersey approach when used for software is a better approach than the MIT approach.") - although outwardly Groove seems to be MIT ("it is more important for the interface to be simple than the implementation"), its structure and the speed with which is was assembled makes me think it's New Jersey really. "In the worse-is-better world, integration is linking your .o files together, freely intercalling functions, and using the same basic data representations. You don’t have a foreign loader, you don’t coerce types across function-call boundaries, you don’t make one language dominant, and you don’t make the woes of your implementation technology impact the entire system.".

InfoWorld has more commentary on Edge Services here and in an extensive interview here. Ray Ozzie spends some time making the point that Groove spaces are securely isolated workspaces, and we need to be careful in softening those edges without providing the right usability cues (what John Seely Brown calls "attuning" versus "attending"). When we built Rendezvoo at Agora, this was an important concern; I think we got it just about right.

Some notes from Rotterdam.

Suite75 organised a wonderful conference - the first of its kind, bringing together Groove developers from a wide spectrum. We've all met online, but for many this was the first real-world contact (I was surprised, for example, to find Suite75's CEO Machteld Wijnands not to be a besuited middleaged Dutchman at all!). Representatives from ten Groove Developer Partners: Suite75 themselves of course, Componentry (USA), Computact (India), Mysterian (Scotland), ParallelSpace (Canada), peer development (Germany), PopG (England), NPT (Switzerland), Symbiant Group (USA), and Virtual Methods (UK). Plus a couple of individuals in proto-partner stages. Most people in this group are actively building vertical solutions using the Groove platform. For some, Groove is the basis of their entire business.

For me personally, this was a "hard work" weekend. To some extent I had to fill the shoes of Steve Wilkinson (our VP Alliances) who needed to cancel his trip at the very last moment; Steve called in Saturday evening for a long conference call with the group, which helped of course. When this meeting was first organised, I was a Groove business partner, not a Groove employee; I know how the land lies on both sides of the fence. It's hard work to present the corporate viewpoint and strategy where, inside Groove, I'm a new kid on the block; where our new COO is proving to be a very effective strategic director (which of course means some change); and where I know some of the answers aren't easy. No, Groove Networks will not take your products to market (but we love to showcase cool applications). No, Groove Networks does not have many people in Europe at this stage. No, version 2.1 will not do (x) (y) (z). Here: our priorities are aimed to build the largest possible (horizontal) market for your efforts, by selling lots of Groove, to big companies and government. We think that this will make all our businesses incredibly successful. It may take a little time. But hey, let's look at Groove in these terms:

• Groove 1.0: cool, surprising, radical.
  
• Groove 1.3: very robust in a wide range of commercial environments.
  
• Groove 2.0: "8; DEPLOY" in InfoWorld.

After a very late night (sooo much to talk about!), another busy morning, coffee, more talking, some code- and pattern-sharing, more demos (the Groove/Autonomy connector triggered plenty of good discussion), some pizza, then I made my farewells and flew home exhausted.

We didn't get to blog the conference yesterday, although I took some notes which will turn up online sometime. Now, the main reason we couldn't blog live was the connectivity. Suite75's main office has a wireless network, so everyone's sitting around doing email and Groove and browsing the web, drinking coffee; but the presentations room was non-cloud.

I haven't asked Tim yet, but I think I realised why his little Groove-to-Blogger tool includes local (Groove recordset) storage of the posts you make. It's because then you can blog offline. The two lines of code needed to turn this on aren't in place yet, but that's a powerful vision, which Groove makes really easy and which is quite difficult to implement other ways. It's an offline web-services client (the calls to the webservice essentially get put in a queue until one of the peers working in the shared space can make a connection to the network).

A small description of Tim's blog-from-Groove tool. It's almost the inverse of what John Burkhardt is building in Groove Edge Services. Blogger implements Web Services, via a small API, which lets developers use XML-RPC calls to make posts to your weblog. This is "Center Services", if you like: the service is running on a big box at Blogger Central, from where it does cool Blogger things to update web pages on actual webservers (such as this one at cabezal.com).
So, Tim's Groove tool

• lives in a Groove shared space, where there's
• some user interface: a field to write text in, a display of the Web page you're blogging to, and a couple of buttons;
• some storage (on each user's device, synchronized by the magic of Groove) holding an archive of past postings (for no particular reason, I guess, other than because it's possible!)

Now, turn this whole thing inside out, and you'll understand Edge Services. In the edge services model there is no Big Central Server, just a whole lot of PCs (at the edge of the network: behind firewalls, on roaming WiFi connections, DHCP-assigned IP addresses, all the usual garbage - you generally can't find a simple IP address to call into these machines). By building SOAP interfaces to the services these PCs can implement - and there's a whole lot of interesting services they can provide - you get a new world of interop between Groove and Web. The magic sauce is somewhere in the middle, using well-known relay points (multiple, many) to be able to call these devices's services (and receive callback events from them) regardless where the endpoints are.

I'm in Rotterdam for the Groove developer conference organised by Suite75. Tim has built a neat little Groove-to-Blogger tool, which we'll be running - together - in a shared space, and posting to this weblog.

I've sometimes wondered about the inspiration behind Groove's superb logo. At last the truth can be told!. (Thanks, Ed!)

Note to self: a good map of Schiphol.

Internet Eats Telco (and about time too!)

Steve Gillmor writes in InfoWorld about "Google, Dave and Ozzie" - and Groove and SOAP (and XML, OPML, Manila, Radio...). Interesting stuff:

"And the whole thing blossomed into this big edge services thing, and it's way, way bigger than anything we imagined, and it's really reshaping the future of Groove." The SOAP Relay "...represents a stable point on the Internet that a calling application calls into, and that server routes the request out to where the client happens to be connected to the network."

When Dave Winer says "closed boxes like Ray Ozzie's product", let it be clear: he's saying that because he wants to, not because it's true (it isn't).

Computerworld: "BT Group PLC last week said it plans to install 4,000 public-access wireless LAN nodes designed to serve mobile enterprise users throughout the U.K.". This is fun. They'll drop WiFi (802.11b) access points in public places. It's a good thing - although I'm not convinced you can easily make money charging for WiFi in public places, and geographic coverage will be some way behind the patchy DSL availability. NTK points out "seems pretty darn ambitious - especially when you take into account that it's currently illegal... Odd isn't it, that BT are so keen on WiFi now they've dumped 3G onto their spin-off MMO2?"

What they should really do, of course, is use WiFi to rescue the railway system. Fit a public 802.11 base station into every railway carriage, and wire 'em to the backbone. Suddenly, travelling anywhere by train becomes so much more productive than driving.

I've been way too busy to blog for a while. Apologies to (both) my regular readers!
Dave Winer asks:

if anyone from Groove is tuned in. Is the new Groove in any way open? Does it support SOAP or XML-RPC or even RSS?

SOAP: one of the Groove components is a SOAP client, which is used quite heavily in the product (many of the centralised Groove services such as the public user directory are implemented with SOAP), but can also be used to call SOAP services in the outside world (such as Google) - there's sample code in the GDK to do this. What you can't do easily - yet - is call up the services of a Groove client (peer) using a SOAP call. For one reason: client devices are regular PCs: they don't often have stable IP addresses, they mostly live behind firewalls, and they're offline most nights. (There are some always-on services in a Groove network, which relay Groove transactions. Wouldn't it be cool if... ahem. Some other time.)

RSS: a long time ago, when I was at Agora, I and Peter and Eilish wrote a tool to get RSS news into Groove; during my Cabezal time I did a couple of bug fixes. It still works, and several people use it. Here's a screenshot. Later I wrote another tool to publish Groove content to Web formats including, inter alia, RSS. Which is one of the formats produced by the Groovelog, a Groove instant-message-publishing application.
(Incidentally, Agora's second-ever Groove tool (an outliner) does OPML).