I have been thinking about this Sun Ray problem a great deal lately (of course) and also looking back at some of my other product experiences at Sun. I was with Sun Ray from the very beginning until well after the launch. I was with JavaStations from the very beginning until very nearly the bitter end (and it was bitter :-) ). In many ways the two were (are) polar opposites. In many other important ways they are quite similar.
Some would say (and some have said) that if you want local processing, get a workstation. For everything else, there's SunRay. But to me that divides the world at an arbitrary line that should be a lot fuzzier and more moveable. This may get me burned at the stake, but in some ways the JavaStation had it right. Of course, the JavaOS was so poorly architected and useless that any good points of the JavaStation were quickly overlooked and lost. But the idea of both a zero-admin clien and local processing has a lot of merit. Not on JavaOS, mind you, but it does have merit. The real question is how do you draw the lines between what gets processed locally and what gets run on the server.
After all, SunRay does have a "local OS" of sorts. It is just very small, and does very little that the end-user would interact with. The "local OS" (i.e. firmware) is upgradeable from the server at boot time via a simple version-check, and all application processing happens on the server.
The JavaStation also had a local OS, it was just much larger and was responsible for most of the user experience (which is why the user experience was so bad). Like SunRay, the local OS was upgradeable over the network via a simple version check, but unlike SunRay, the applications could also be stored locally and were run locally. This allowed for disconnected use of a JavaStation (and I know I'm using a loose interpretation of the word 'use' here, but bear with me) with an embedded application. So what if we had a real OS locally? Say a tiny, stripped-down version of Liinux, Solaris, or even Mac OS X? Stripped down to the point of only providing Networking, UI Display, Browser, and Java.
For UI Display I would suggest that the most minimal windowing/display environment be brought up -- like an empty X Server, or an Aqua Desktop with no apps, toolbars or Docks. From there I add the Browser and Java, so that a user has access to any and all web-based applications they might need. The browser and Java are stored locally, for fast execution and disconnected use (and don't ask "what use is a browser or Java if you're disconnected?" I might address that later, if I have time). I could even add some small, simple embedded applications like calendaring, email, video decompression, etc. to the local footprint, depending on what the useage pattern might be.
Looks like a workstation, doesn't it? In some sense, yes, but it has no disk. It has no local management, etc. I can even see the ability to load drivers over the network as needed. Say I plug in my USB Webcam. The device identifies itself to the OS, which then contacts the server and asks for a driver for that device. If the server has a driver for that device, it is sent over the network and dynamically loaded, and the device works. When I unplug the device, the driver is unloaded and marked for garbage collection. This also gives me a central way to manage what devices end-users can attach. Users in group A can attach any storage device. Users in group B can attach any read-only storage device. Etc.
So, you see, JavaStation had some really compelling ideas driving it. It just had square wheels.
More later ... I have to get some work done.