|
Since TSpaces basically
connects all things to all things, there are many things it is good
at. Also, since it is main memory and Java, it is also ideal to
do many things on very small devices, even those (maybe especially
those?) that do not have disk drives. So, sure you can build a chat
room application, a shared whiteboard application, a distributed
cut and paste buffer application, a remote file system viewer or
tons of multi-user games.
However, there is one
main thing that we think TSpaces will be especially good at.
It can (will?) be the common platform on which we build links to
all system and application services. What do I mean by that? Suppose
I want to print a file on a network printer from a generic client.
That's fine if I have a UNIX client and a UNIX network. It's a little
more involved if the client is Win NT or Win95 and much more involved
if the client is an Apple. However, what if the client is a PDA?
At a large site, such as ours, how do I go about adding all 100
network printers to my Pilot interface? How do I even add one? Now
look at it from the other side. When I have a private locally attached
Win 95 printer (or Mac printer, etc.), how do I access that from
a UNIX machine? Sure, there are specific answers to some of these
problems, with regard to printing, such as running a specialized
LP Daemon program that will talk to UNIX print clients. Now let's
cover scanning, faxing, email, paging, application services (e.g.
convert a word document to a postscript file, invoke a web search
on a topic, fetch and parse XML data) or remote device control (e.g.
drive a network attached machine through an API, access a remote
drive).
In the TSpaces world,
a common computing environment, with access to all possible network
services, is surprisingly easy to build. A set of applications,
written in Java, map the system-specific service (e.g. printing
service) or application (e.g. web search) to a standard tuple representation.
Then, any client from any platform can generate a tuple and send
it to a TSpaces server. Applications, listening for specific tuples,
pick up jobs when they see them and execute them. (This is all fairly
fast, since it is implemented with an underlying memory-resident
database system.) In building this environment, one would write
the service application to run on the platforms where they could
do the most good. At the IBM Almaden Research Center, most network
printers are visible to AIX systems. Therefore, one AIX printer
service application could listen for tuples posted to the "printing
space", pick them up and send them to an AIX Queue. Similarly, queries
about queues and print status could also be done. Then, on every
other local printer that should be attached to the common platform,
a user simply runs the local print application (although, in practice,
the local application can probably handle a number of services).
Notice, however, that we are NOT trying to replace any existing
tools or services -- we are simply augmenting them with platform
independence and flexibility.
One of the really cool
things about this environment is that it injects a smart middleman
into the picture. So, as mentioned above, you can build this nice
platform independent print service that gives you access to any
printer in the building. That might be ok, but perhaps you don't
have a clue about where all those printers are. With a smart middleman,
you can add intelligence. When your PDA includes a location sensor
(with no sensor you just have to tell it which room you're in) the
smart middleman printer client locates the non-busy printer nearest
you (that still has paper and toner) and sends the job there --
then shows you a map of how to get there. When visiting a new location,
this sort of service would be incredibly convenient.
The number of common network
services is limited only by our imaginations. We're counting on
the university population to come up with some revolutionary ideas.
We've thought about cool ways to incorporate PDAs into the network.
If they run Java, then great. If not, then they will have to communicate
some other way, such as using TCP/IP and sending only primitive
types in the message.
There is one more important
point to make (or two, depending on how you count). First, this
creates a single interface for talking to practically every single
service that exists on the network -- everything uses tuples. The
exact language that goes inside the tuples will have to be ironed
out over time, of course. Second, while this all works fine from
a command line or GUI interface, tuples can be sent from programs
(from Java programs or from programs that invoke Java programs).
That means that your program can easily send email, faxes, pages,
print jobs, web searches, remote device commands --- all as easy
as sending or receiving a tuple. We've been waiting ages for smart
agents to act on our collective behalf. One of the things that has
slowed down their progress is the interaction to the outside world
(so many different platforms, so many different interfaces, so little
time).
|
|
|
