Re: Help me to add java program to my world

We're still preparing things for release, but the code base is at  
http://hedgehog.software.umn.edu:8888
The repository has been mentioned in various context on discussion list:
https://lists.wisc.edu/read/search/results?
forum=croquet&words=hedgehog
+repository&in=3&any=0&max=100&skip=0&orderby=CreatStamp_+DESC
And there's a nice movie explaining how to update (http://
hedgehog.software.umn.edu/croquet/croquetMovies/updateToMotion.mov)

Note that the stuff in the repository is not "released", but is made  
available in the sense of David Reed's description of Croquet as  
"invention in public."

For more information about the Squeak technology used for the  
repository itself (e.g., tools to manipulate code-bases), see
http://www.google.com/search?q=squeak+monticello

----------
The VNC support in the repository is under "Contributions" repository  
in the "Wisconsin demo" example -- which you should note as  
indicating that it is not part of the core Croquet technology.

The Wisconsin demo gives two examples:

1. The Admin->New raw RFB menu item  sends KMenuBar>>actionNewRFB,  
which is a straightforward application of the new TEmbeddedApp  
mechanism to Ian Piumarta's remote framebuffer implemenation of VNC  
for Squeak.  Each replicated TEmbeddedApp (on each participating  
Croquet user machine) is associated with an XrfbClient (in the same  
Squeak on the same machines, but outside of Croquet) which each  
connect to the same shared VNC session on the server.

Thus VNC does what it does well: provide a shared session on a server  
which a bunch of folks connect to.  The "replication" is really done  
by the VNC "shared display" technology. The TEmbeddedApp stuff just  
forwards ONE of the replicated inputs to the server, and allows each  
Croquet client to display the wall-clock current-time display.   The  
VNC server-time is only loosely coupled to Croquet simulation-time.  
[N.B.: I sure hope this description is right! I haven't been working  
with this code lately, and I wouldn't be surprised if there's a bug!]

Note that you will still need to run a vncserver somewhere.  In the  
usual default implementation of VNC servers, the client has access to  
a full desktop on the server. With this client appearing in a Croquet  
space, all the Croquet users in the space will have access to the  
full desktop of the server as if they were sitting at the server  
console. This is not likely to be the right thing for production use  
-- either in terms of security or in terms of useability.

2. The New->Desktop... menu item sends  
KStandardHarness>>makeDesktop:, which is the START of a more  
production-oriented version of the above. The Croquet user that first  
creates the new desktop is prompted for a URL, which is given to each  
replicated instance of the XrfbClient embedded application. The idea  
here is that the clients do not just create to a wide open desktop.  
Instead, they each use a simple http protocol to pass the url and  
ObjectID to a little server running somewhere. That server ensures  
that there is a "jailed" vnc session running "just the right  
application" only (creating the session if necessary), and answering  
the appropriate VNC display number for that session. The client then  
connects to that display.  For example, of the URL ends in .pdf, the  
server runs a PDF viewer in the VNC session. If one of the users  
exits the PDF viewer, everyone is just left with a useless background  
and no shell in which to create trouble. If the URL ends in .doc, a  
Word-compatible application is run. Otherwise, Firefox is run.

All of this fancy server-side stuff is probably way more than you  
need, and I don't really recommed trying to emulate it.  It's real  
purpose is to be able to have an open demonstration of a Croquet  
connection to a VNC server, and for security reasons, that's just not  
likely to happen using the raw stuff of (1).  Alas, all this  
demonstration stuff is not released yet. However, the repository is  
open, and you can download and use it. The fancy XRFB server is  
running, and you're welcome to use the software to connect to it.  
Just be aware that it's still being worked on.

NONE OF THIS HAS HAD ANY TUNING. We're taking an approach of 1) make  
it work, 2) make it work reliably enough, 3) make it work fast  
enough. I figure we're pretty close to being done with 2 (but not  
quite). I think the performance is within an order of magnitude of  
being good enough for many purposes (and my experience is that if a  
first version is within an order of magnitude of good enough, then  
tweaking can get it the rest of the way). But I do NOT think that  
this particular approach is ever going to be fast enough to, for  
example, play a highly-responsive Flash Internet game in a browser on  
a remote VNCserver displaying in a client within Croquet.

On Dec 17, 2006, at 2:04 AM, Patrick Pabeda wrote: