Well, there's integration and then there's integration.

One thing the Wisconsin package in the repository does is let the user specify 
a URL to create a connection to. The system brings up a shared Remove Frame 
Buffer display (aka Virtual Network Computing) to a Unix server.  If the URL 
ends in .doc, it brings up a Word clone (OpenOffice). If it ends in .pdf, it 
brings up an Acrobet clone (evince). No .xls support yet, but OpenOffice 
should handle that. Anything else, and it brings up Firefox.

The effect is that the users of the space have a series of "virtual table PCs" 
that are each dedicated to a particular application -- i.e., a program 
operating on a particular data file.  Instead of opening and closing 
executables on dead files on your Windows desktop, you have long-lived 
"objects" that embody the application AND the data in one.

Under the hood, there's a little protocol whereby the Unix server is running a 
little python HTTP server to launch these applications in a sandbox. That is, 
you don't see the full Unix desktop -- instead, each virtual tablet PC panel 
is trapped to just that one application.

There are a couple of issues here. Some temporary, some deep:

* It's relatively slow. This is improving rapidly as we tune it, but I don't 
  think it's ever going to be fast enough to run First-Person Shooter games in 
  a browser on a remote system within Croquet. It should (soon) be fine for 
  .doc or .pdf or normal Web browsing.

* Neither the application nor the data are "in" Croquet. Suppose you edit a 
  file and want to save it. As it stands now, it would save on the server. 
  Managing files and versions and copies is a mess that Croquet is 
  successfully designed (as I view it) to avoid. But this non-Croquet stuff 
  brings those issues back. Also, for the server to see the file in the first 
  place, it has to be world-accessible via http so that the server can fetch 
  it via the specified URL. We can address both these issues after a fashion 
  by having a means to get files from/to your disk to the server, but that's 
  not a Croquet issue.

* As with any shared VNC application, all users have the same security. I hope 
  and believe that long-term, we can arrange for different security to be on 
  different UI objects that at least appear to be within the same space. But 
  this is a bit past my current time horizon. And even then, it will only 
  allow for different access for different users of different Croquet objects 
  (e.g., the display panels), not for individual operations within the foreign 
  application. (I.e., we can't fix Windows(TM).)

* This approach essentially makes a window that punches a whole through the 
  fabric of Croquet to legacy applications. Some consequences (in addition to 
  file management and access) are that the model of time and objects is 
  different. Croquet is designed for everybody to see the same thing at the 
  same Croquet-time. What's happening on the VNC server is happening in the 
  server's real-time. And the objects at the far end of the VNC "window" or 
  "tunnel" can't interact with objects in Croquet. For example, you can't drag 
  an object within a foreign Web browser off the display panel and onto some 
  other Croquet object. These issues probably don't matter at all for legacy 
  applications, which aren't designed to support coordination between 
  applications anyway. But as Croquet environments get richer and get designed 
  to take advantage of such concepts, a VNC-based solution is going to start 
  looking pretty hokey.

All these issues are not peculiar to RFB/VNC, of course. You could do use the 
RFB stuff as a model to punch an analogous hole to display LOCAL Java, .NET, 
or whatever you want. Andreas has written a powerful EmbeddedApplication 
framework that is used underneath the RFB stuff. One additional issue you 
would face (that RFB covers) is what should other folks in the space see? Do 

Howard Stearns
they need to have the same applications and data files on their computer?