Email: A P2P Enabler?
by Rael Dornfest
Dave Winer is href="http://www.xmlrpc.com/stories/storyReader$1401">experimenting
with RPC (specifically XML-RPC) over SMTP (read: email). I've been doing a little fiddling along much the same lines using SOAP (specifically
SOAP::Lite's fledgling support for SMTP/POP). Could email possibly be
a somewhat useful Peer-to-Peer / Web Services enabler?
The thought first crossed my mind whilst playing with Microsoft Outlook's
invite-via-email functionality. Groove, too, uses email as one possible
means of invitiation to a group space. The idea finally took root and
began to grow after a chance mention of a need for store-and-forward
capability in some P2P system or other (I forget which, I'm afraid). I've
been trying to shake it ever since.
But email ain't P2P!
Email is not usually considered Peer-to-Peer in even the broadest of
definitions. It does, nevertheless, fit squarely into what one might term
"Appear-to-Peer" (thanks to Dale Dougherty for his off-the-cuff coinage).
The pedantics of plumbing aside: I send email to you and you (hopefully)
send email in reply. Couldn't, then, such suspension of disbelief be tolerated
by a P2P or Web Services framework?
For pity's sake, why?
Email actually solves or circumvents some interesting problems being
re-solved (or not) by P2P and Web Services efforts:
Email skirts the firewall issue by remaining simply a pull medium.
The winking in and out of existence of Napster nodes is considered
a non-issue due to the ubiquity of any particular MP3. But what
of the singleton meant for a particular node -- a node currently
offline. ICQ is (was?) unique in the instant messaging space in
providing delayed delivery of a message to an offline buddy. POP
does the same for email
- Unique Addressing
While an email address is indeed tied to one server (or farm thereof)
in particular, from the Appear2Peer perspective, firstname.lastname@example.org
lives in my email client.
The pervasiveness of email's existing infrastructure goes a long way to rendering moot concerns
about critical mass of deployment.
A pet concept
Not quite worthy of the term "pet project," I do have an application
swimming about in my mind and ~/src directory.
An RPC-over-SMTP proxy running on the local desktop or server facilitating
communication between local P2P / Web Service apps and the outside world.
The proxy brokers interactions, tracking, routing, storing, and forwarding
the asynchronous requests and responses, cacheing when useful and appropriate
to do so. Obviously the proxy should not be limited to RPC-over-SMTP,
allowing for synchronous communication over HTTP whenever possible.
Dave's absolutely correct in referring to these shenanigans as "messaging." . After all, isn't an email client set to send immediately and retrieve every 1 minute just low-tech IM?
Almost Instant Messaging? MailStorm?
(I'll continue to fill in this entry as my thoughts and coding coalesce.
And, of course, I invite any constructive criticism you might have to offer.)