File-Sharing That Works
Peer-to-peer networking has a serious—don't laugh!—use as a collaborative development tool.
I sent the club a wire stating, Please accept my resignation. I don't
want to belong to any club that will accept me as a member.
Remember peer-to-peer technology, more familiarly known as P2P? Over
the last few years, P2P has followed a parabola that fits right in with
the dot-com boom and bust. First came Napster, which splashed P2P all
over the public consciousness and spawned a host of imitators (some of
which have outlasted their once-proud but sued-out-of-existence parent).
Then came a time when every struggling Internet company was going to add
P2P features to their products. (“I know! We’ll be the best
peer-to-peer banner-ad-driven dog-food sales company on the Net!”)
Now that the dust has cleared, most of those projects have vanished, but
there’s still a hard core of P2P efforts left—and some of them
can be very significant for developers.
No, I’m not talking about file sharing that cloaks copyright violation
in a veneer of freedom. Rather, I’m thinking about serious attempts
to promote collaboration through software. There are three in particular
you might want to look at, from Borland, Microsoft, and Groove.
When P2P Just Works
My first example of useful P2P technology is in a place you might
not think to look: Borland’s CodeWright text editor. CodeWright is
a high-end programmer’s editor with a $299 price tag; you can learn
more about it at http://www.premia.com/.
While CodeWright has hundreds of features, I only want to mention one
of them here: it’s called CodeMeeting.
What CodeMeeting does is embed a P2P communications layer directly in
your text editor. When you enable CodeMeeting, you gain the ability to
connect your editing session with that of another user (provided that
you can make a TCP/IP connection with their computer). This gives you
two things. First, there’s a chat window that opens up so you can
communicate by typing. Second, you can share documents. Shared documents
can be edited by either user (though only by one user at a time), and
changes show up on both computers.
I see CodeMeeting fitting precisely at the intersection of two trends:
telecommuting and pair programming. Need to pair with someone who’s
not in the office right now? Fire up your copies of CodeWright, load the
current source file, and away you go! The simple “pass-the-baton”
style of controlling who can edit in the file at any given time fits perfectly
with the pair programming paradigm as well. Sure, you won’t have
quite the bandwidth typing comments that you would if you were sitting
right there and listening to tone of voice (though voice over IP or videoconferencing
might offer a nice complement to code-sharing), but you’ll be way
ahead of just sending anguished e-mail to the distributed members of your
P2P From Redmond
Exhibit B in this particular case is the Windows XP Peer-to-Peer
SDK, part of the Windows Peer-to-Peer Networking initiative (you can find
out more at http://www.microsoft.com/windowsxp/p2p/).
Released in beta form early this year and made final this summer, the
Peer-to-Peer SDK offers a set of APIs built on top of the low-level WinSock
API. These APIs provide security, peer-to-peer name resolution, replication,
and other very low-level services useful in writing P2P applications.
Don’t expect to find any finished applications in this SDK; that’s
not its purpose. Rather, expect future versions of Windows, as well as
applications software from Microsoft and other vendors, to build on top
of these APIs.
Interestingly, the P2P APIs defined by Microsoft depend on IPv6, the
next generation of TCP/IP, for their network layer. This represents a
bit of a gamble on Microsoft’s part, but may pay off if IPv6 takes
hold and they already have software out to take advantage of it.
If you’re thinking about P2P applications and want to write on the
lowest-level APIs available for performance reasons, this is where you
ought to be looking in the Windows world. I would not be at all surprised
to find a future version of Windows or Office requiring the installation
of these services to enable collaborative scenarios that we can barely
P2P In the Groove
Microsoft isn’t the only player in the P2P API space for Windows—nor,
in my opinion, are they the leading contender. I’d give that crown
to Groove Networks. Groove Networks (http://www.groove.net/)
are the vendors of the Groove Workspace, a collaborative environment with
the slogan “software that effortlessly keeps people, information,
and PCs in sync.”
Groove has peer to peer underpinnings, but it’s much more than a
simple file-sharing program. To users, Groove is simple: it’s a place
to collaborate. That means you can open up Groove on your on machine,
create a workspace, and invite other people to join in. Everyone in the
workspace can share files, and calendars, and discussions, and other tools.
Every user sees Groove as a local application (and, in fact, it replicates
data to every computer involved in a workspace). But beneath this local
application is an infrastructure that handles such issues as secure communication
through firewalls, data compression, and replication with reconciliation.
Like CodeWright, Groove doesn’t especially brag about being P2P.
Rather, it concentrates on implementing useful capabilities atop the basic
Groove infrastructure. Groove includes tools to do things like collaboratively
edit Microsoft Office documents or create outlines or browse the Web together.
More importantly from the developer standpoint, Groove includes APIs to
let applications from independent vendors take advantage of the Groove
infrastructure. You can buy tools in areas such as project management,
proposal development, and UML modeling from Groove’s partners. Or,
if you like, you can visit Groove’s developer section and learn how
to take advantage of these APIs yourself.
Of special note in recent months is the release of the Groove Web Services
set of APIs. While the first generation of Groove applications were hosted
within the Groove user interface, Groove Web Services provide a standard
SOAP-based way for external applications to take advantage of the security,
transport, transaction, and other services supplied by Groove for peer-to-peer
So if it’s so great, why isn’t everyone using Groove? So far,
they’re suffering from the classic early adopter problem. Networking
is great when you can expect everyone you know to have the appropriate
software; it doesn’t work well for the first users, unless the people
you know are also early adopters. Groove is working to change this by
giving away the Preview Edition with enough functionality to be useful,
but they have a ways to go before their infrastructure is pervasive. In
addition, I’ve found the current Groove software to be somewhat resource-intensive,
perhaps because of their use of non-standard graphics widgets. I’ve
used Groove for some collaborative projects, and it’s been wonderful—except
for the problems of getting other people to install it.
If you’ve dismissed P2P as “that file-sharing stuff,”
I think it might be time to take another look. What unites the products
from Borland, Microsoft, and Groove is the commitment to a P2P fabric
as an infrastructure for applications where communication between clients
without a server makes sense. This isn’t about circumventing copyrights;
it’s about empowering people to work the way that they naturally
do. I think we’re headed towards having P2P connectivity be as ubiquitous
as TCP/IP or even the telephone dial tone.
In a world of dynamic teams and agile development, the tools that enable
people to structure their workload for rapid information sharing and collaboration
will be the tools that win in the market. Are you going to be the one
who helps write those tools?
Got an idea for a great P2P tool? Or are you ready to just pull yourself
off the network and ignore all this stuff? Let me know your experiences
either way by e-mail to MikeG1@larkfarm.com.
I’ll use the most interesting comments in a future issue of Developer