interaction – Wetmachine

Subsumption Assumption

Stearns May 25, 2009 - 8:34 pm February 25, 2013Inventing the Future, meta-medium

Ack, this was sitting in my drafts folder for nearly a year. At the time I started it, someone had asked about how one might use Croquet virtual worlds to subsume other technical functions in the same way that the World Wide Web has incorporated other resources and functions. I did five minutes on the taxonomy of the problem-space.

I should have just answered with this video of Intel’s John David Miller demoing the use of Twitter from within a Qwaq Forum. He fills in the stuff on the Twitter Web page (crappy hand-held video, below) and then I love how the audience guy asks, “And then you can bring the result in to the world?” JDM answers that it already is, and dollies back to show that the whole interaction has been in world the whole time.

Reminds me of this from way back when.

Sounds Good

Stearns May 21, 2009 - 3:21 pm February 24, 2013Inventing the Future, meta-medium

One of the general internal themes of Croquet is that everything ought to just work, and work well. Most practicing software developers aren’t fortunate enough to be able to create artifacts like this because the software is aimed at addressing a very specific problem. That tends to lead to tools of limited scope and interaction.

Consider sound. If you only want to make voice chat work, you can use a low fidelity encoding on a lossy transport. It will do what it does well, but only that. Now suppose you and someone else are watching a movie and discussing it, using separate programs for the movie and VoIP. Either program might work well, but use them together and everything is likely to go to hell.

Time Shifting

Stearns May 19, 2009 - 2:40 pm February 25, 2013General, Inventing the Future

I don’t remember hearing the phrase “time shifting” before VCRs and DVRs. I now appreciate the value in being able to capture something while I’m doing something else and then view the capture later when I think I’ll have more time. With digital photography I can easily and sloppily capture my world and shift the difficult task of composition and editing to a later time. (Like, after I’m dead maybe.) I thought I learned in economics that land was the one universally limited resource, but I think that finite time is far more significant. Any tool that helps me shift time is valuable.

Scaling to the Enterprise (Part 2 of 4)

Stearns June 17, 2005 - 9:22 am February 24, 2013Inventing the Future, metaphysics

2. HOW MUCH USE CAN THE APPLICATION SUPPORT?
(See part 1.)

The architecture of Croquet is very different from that of, for example, J2EE applications. In a client-server application, one server or server “farm” must process each and every interaction initiated by the thousands or millions of users. The only thing processed on the end-user’s computer may be as little as the HTML formatting of the text and image results. Every single other computation must be handled on the big-iron servers. To double the number of users, the capacity of the servers must be doubled. It should be no surprise, then, that so much effort goes into trying to squeeze out each available computing cycle in such architectures.

When an application has state — that is, when results depend on previous results rather than simply generating static files — client-server does MUCH worse. The amount of storage required can go up much faster. In some cases the application state depends on the number of possible connections between users or between applications. The storage (and certain kinds of search-like operations) increases as the square of the number of users or applications (N^2, c.f. Metcalfe’s law). But we are particularly interested in allowing students and faculty to form their own ad-hoc groups among which to communicate and solve problems. A client-server architecture hosting such “group forming” applications would grow exponentially to the number of users (2^N, c.f. Reed’s 3rd law). With only a few users, this architecture would not work at all, no matter how (finitely) fast the servers, or what language the application is written in. (See Reed’s discussion for a surprisingly accessible treatment of value, saturation, and other issues.)