oreilly.comSafari Books Online.Conferences.
Articles Radar Books  

How Ray Ozzie Got His Groove Back
Pages: 1, 2

Jon: Groove uses a central relay server, if available, to store and forward messages, and to proxy connections between firewalled devices. This service is one of the business opportunities that Groove Networks, Inc., your company, has staked out. What are some others? And what are the opportunities for other players to deliver Groove-aware services?



Ray: Groove applications and tools are built with contemporary "component" technologies; Groove dynamically assembles applications by automatically downloading the requisite components from the Internet. In many cases, companies will wish to serve their tools to many, many consumers in a scaleable manner. For this reason, Groove offers its customers component hosting services, so that applications (as well as updates to those applications) can be delivered to millions of consumers quickly and efficiently.

Another service that Groove will provide is a backup service. This service is designed to give users confidence that they can recover everything stored on a device should the device be lost or stolen.

Because Groove is fundamentally based upon XML technologies, and because we fully integrate XML-RPC and SOAP services directly into our platform, it's very straightforward to communicate with Web-based services. Thus, we fully expect that many players will offer Web-based transaction services, information services, search services, etc., that are fully interoperable with and leveragable by Groove applications and solutions -- whether or not originally designed to be used in conjunction with Groove.

Jon: To the user, the Groove transceiver looks like a suite of applications -- chat, sketch, notepad, discussion, file archive. These apps are Groove-aware. When users make changes, the apps modify the Groove data model, causing updates to be written to the encrypted object store on the local disk, and also sent as encrypted packets over the wire to synchronize with all other Groove endpoints involved in the shared space.

Users, of course, will immediately wonder how they can achieve the same benefits with the best-of-breed apps they're already using -- for example, Visio instead of Groove's built-in Sketch app. What are the prospects for integrating popular apps with Groove's data model, so they can enjoy the security and synchronization features of the platform?

Ray: Groove tools use COM as their component model, and thus are afforded tremendous leverage when run on the Windows platform. For example, we've implemented an ActiveX wrapper component that enables us to add collaborative capabilities to many existing ActiveX components such as Microsoft's PowerPoint, Autodesk's WHIP!, and Macromedia's Flash, by transferring property changes and events between computers in a synchronized manner.

That said, we'll surely be working to enlist other software developers to build creative, interesting and useful collaborative tools for the platform -- either from scratch, or by enhancing existing application componentry.

Jon: You've said that Groove implements the model-view-controller paradigm. Can you describe what that means in the context of Groove, and describe the various APIs that developers can use to add value to Groove?

Ray: Groove applications are constructed using the MVC application-factoring design pattern that originated, I believe, in Smalltalk-80. In Groove, this generally means that the View components are the platform-specific user interface design elements such as UI controls. The Model components are the 100%-portable components that store data and expose interfaces and methods to effect changes on that data. The Controller components are the glue that binds the Model and the View, and in essence contain the business logic of the application.

The vast majority of developers will begin by writing simple Controller-level applications, using any of a vast variety of standard View and Model components that we supply. These applications are written by supplying an XML meta-description of required components, along with some code -- generally in a scripting language such as JavaScript -- to bind UI events to things that are intended to happen in the View and Model. Most of our own tools involve anywhere from dozens to hundreds of lines of scripting-level code.

A more sophisticated programmer may wish to implement new UI controls or new data models, and will generally do so in a language such as Visual Basic or C++.

Jon: Groove's adaptive communications layer ensures that the product will always work, configuration-free, even behind firewalls and NATs. How does it do that?

Ray: The product's communications layer is quite sophisticated. Without going into agonizing detail, it has the capability of dynamically sensing what communication adapters or interfaces are active at any given time. For each, it understands the dynamic performance characteristics at any given time, and what obstacles are between it and the open Internet such as NATs and firewalls. Furthermore, it can do protocol adaptation, using a variety of things such as UDP, a specialized compressed multiplexing protocol over TCP/IP, or HTTP, as necessary. It even has the capability of throttling its own use of communications resources, so that it doesn't unnecessarily interfere with foreground browser activity.

How does it do that? It's a mere matter of code.

Jon: It's tempting to imagine that wireless networking will soon make the disconnected client an endangered species. Obviously, though, you've put a huge amount of effort into ensuring that Groove does support the disconnected client. Why?

Ray: I believe that the ubiquitous, high-bandwidth, always-on, wireless Internet is a fallacy. Many 3G experts believe that many if not most cells will exhibit bandwidths in the 50-to-150kbps range, as opposed to the megabit numbers being touted. As today, sometimes you'll be in-range, sometimes out, sometimes moving between cells, sometimes moving through tunnels, sometimes in an elevator, sometimes in a building, sometimes on an airplane, sometimes in your basement.

And look at the current wired Internet. There is no less than a three-order-of-magnitude difference between the 45 Kbps of many dial-up connections to the 45 Mbps of many college dorm T3-over-100baseT connections.

We designed our product pragmatically -- for a real-world Internet of variable bandwidth, variable latency, variable jitter. Furthermore, we believe that "disconnected mode" is something that is not only a reality from a connectivity perspective; it is also a reality from a workstyle perspective: sometimes you simply want to disconnect, do work, and then share the results.

Jon: Groove today runs only on Windows, yet the aim is to be ubiquitous. Will the product be ported to flavors of Unix and to the Mac? Will it scale down to PDAs?

Ray: Although we're not announcing our non-Windows platform plans at this time, we are indeed demonstrating a Linux port. The product was designed with a multi-platform porting architecture, with an eye toward "best of breed" user interface on any given platform, but also permitting full-fidelity data synchronization regardless of UI.

Jon: Groove's minimum requirements -- 233-MHz Pentium, 64 Mbytes RAM -- push somewhat beyond the center of gravity of the PC installed base. Likewise, the download size of about 10 megabytes is a bit daunting for the 56-Kbps modem crowd. How significant are these obstacles for rapid and wide adoption of the product?

Ray: Initial system requirements were chosen conservatively for our Preview Edition 1; they are likely to shrink. The download size is indeed a substantial download for a modem user, however -- to put it in perspective -- it's about half the size of AOL or a browser download, or about the size of Layla as an MP3. OK, think Crush, or Firestarter.

In this day and age, for corporate users, for campus users, for cable and DSL users, surely it's not going to be a problem. For modem users, if they hear that it's useful or cool, or if they have a close friend or coworker who wants to interact with them, they'll download it.

Jon: Groove's trust architecture is more analogous to PGP, or SDSI and SPKI -- which we had better spell out as Simple Distributed Security Infrastructure and Simple Public Key Infrastructure -- than it is analogous to hierarchical x.509-style PKI. Why did you take this approach, and how will it make life easier for users?

Ray: Groove was designed from the outset to support the way that people really interact with one another in small groups. That is, in a small group, I don't need a certification authority to tell me that Jon is Jon -- I know that Jon is Jon. I recognize Jon because I work with him; I know him.

When we set out to build the product, the closest thing to my requirements was PGP's web-of-trust model. It was a great mental starting point. The result is a product oriented around a peer trust model for dynamic peer group formation, but one that internally supports x.509-style distinguished naming, so that we can service a customer who has made an investment in client-side certificates.

Jon: Groove looks like a great way to help users work around the IT bottleneck, creating for themselves the secure, distributed, and universally-accessible workspaces that they desperately need. Why shouldn't IT fear Groove, though? How can Groove help IT manage the empowerment that Groove's users enjoy?

Ray: Groove solves many problems that are high priorities right now for IT. If you look at virtually every major enterprise worldwide right now, they're deeply entrenched in partner relationships. Structured partner relationships such as supply chains, semi-structured partner relationships such as product design partners, less-structured partner relationships such as external Web design shops, accountants, lawyers, and so on.

In each case, the IT person is hammered by one set of people asking to let their partners "into the network" by exposing a VPN to them, and another set of people asking the IT (or line-of-business) group to develop an "extranet" or "portal" for the partner -- essentially a controlled crack in the firewall.

But many if not most interpersonal relationships between partners operate in more of a symmetrical manner. Extranets or portals generally operate in a unidirectional manner, and the site capabilities are generally relatively static and limited. Opening a VPN "hole" in the firewall for a partner is very, very rare because it's so difficult to control.

So what happens? Everybody uses e-mail ... because it usually works. Regardless of how clunky the rendering is, regardless of whether it looks the same on either side, regardless of how unsecure it is. It just works.

Groove enables the IT or line-of-business manager to create workspaces that are much more appropriate to the task than plain e-mail, when the task involves collaborative design, supply chain exception handling, or product support, among many others. But these workspaces operate across the firewall transparently and in a highly secure fashion. It's like a highly secure VPN that is limited to the scope of a relationship or a project. It's more in the hands of the participants than a centrally-designed extranet or portal, and far more controlled than a raw VPN.

Jon: It's obvious why enterprise IT should care about Groove's automatic and comprehensive security. Why should ordinary users, who are just chatting with friends and sharing photos with family members, care about security?

Ray: Although this is highly individual and personal, let me reduce it to this: Security, control, and privacy are intimately related, and they mean a lot to us. And we hope that they increasingly mean a lot to you.

The things that you're sharing with your friends and family within Groove are not occurring on our Web site, or anybody's Web site. Nobody's recording what photos you're looking at, and nobody designed the application awkwardly in order to monetize your page views. Nobody is watching how you interact with your friends and family, and trying to figure out why so that they can sell you something. Nobody's going to take your photos away when they realize that they can't sell you anything that you don't really want.

Related:

The Peer-to-Peer Directory

The O'Reilly Peer-to-Peer Conference

A New Groove - DevX's interview with Ray Ozzie

P2P News from Meerkat

More from the P2P DevCenter

And it's not just about photos. It may be about family health issues that you're discussing with your doctors or your close friends. It might be about personal and private financial or legal matters.

Groove is a tool that is intended to help you to communicate with the people that are important to you. If you find it useful and valuable for those communications, as I know that many will, you may ultimately buy enhanced versions of the product and services from us. You'll also likely buy tools and solutions from our partners that will make it even more useful.

Groove isn't an indirect marketing play. It's about enhancing the value of the pipe that is connected between us, in a way that gives you control and respects your privacy. It's a way for you to share and do things with the people who are important to you. It's about value, and trust.

Jon Udell is an author, information architect, software developer, and new media innovator.


Return to the P2P DevCenter.





P2P Weblogs

Richard Koman Richard Koman's Weblog
Supreme Court Decides Unanimously Against Grokster
Updating as we go. Supremes have ruled 9-0 in favor of the studios in MGM v Grokster. But does the decision have wider import? Is it a death knell for tech? It's starting to look like the answer is no. (Jun 27, 2005)

> More from O'Reilly Developer Weblogs


More Weblogs
FolderShare remote computer search: better privacy than Google Desktop? [Sid Steward]

Data Condoms: Solutions for Private, Remote Search Indexes [Sid Steward]

Behold! Google the darknet/p2p search engine! [Sid Steward]

Open Source & The Fallacy Of Composition [Spencer Critchley]