From: jason_watkins@...
Date: 2005-04-16T15:49:36+09:00
Subject: Re: What's beyond Rails?

>>>
The web client issues the command to the server, the server churns on
this for a few seconds, and sends the
whole image down the pipe again ...
<<<

Still the wrong model. If you were providing Photoshop as a web
application, presumibly you'd be providing storage on the server
itself.

So after your guassian blur filter runs, the app only need to send you
back a ~1000x1000 pixel image that reflects the portion of the image in
display.

If you've worked Satori you can understand how non-destructive editing
with a transaction log works. Your interactions create a log of actions
to complete, and the view is computed on demand... but the entire
calculation need not be done at the full resolution for the entire
file. Logging the actions and generating a preview is sufficient. After
editing is complete and it comes time to save results, then you can
render the transactions at the output resolution.

>>>
That
doesn't sound like so much until you realize you have to have that wait
every single time you zoom in or out, or scroll up or down, or even
change the background color from white to transparent.
<<<

Once again, there's no reason to assume our client is brainless. Much
like google maps maintains a tile cache, we could maintain a cache of
layered tilings. Of course it's not going to be as responsive as
communication on a local machine.

My point is merely that http itself is not the limitation.

>>>This is similar
to the problem faced by online FPS engines: Since you can't rely on
subsecond response times when you're playing CounterStrike over the
network, the server has to give the client more information than
strictly necessary and trust it to do what's right until the next time
contact is established.
<<<

While that's true for modems, it's not necessarily true once you get to
broadband. This is a complex topic with a lot of details. I happen to
have a friend who works professionally in this area. I've played
versions of quake3 that remove all prediction and run at a locked 60hz
rate both for client side graphics and network state update. Latency
isn't necessarily the same as throughput, and human beings are
surprisingly tolerant of latency. You can hit up citeseer for the
relevant basic research done by the .gov in the initial military
simulation days: the net result is that humans can tolerate as much as
150ms of local lag, and that at around 50ms of local lag human
observers begin to have trouble distinguishing between lagged and
unlagged input.

50ms round trip is possible on broadband these days, though not assured
coast to coast in the US or anything.

Anyhow, the point is not weither it's a good idea to do PS as a web
app. I think it's a miserible idea. The point is that html+javascript
rendering is sufficiently fast to serve as the basic drawing layer of a
GUI abstraction. Of course something purpose designed for it would be
better, but with the possible exception of flash, I don't think
anything is going to get enough market penetration: html+javascript are
good enough (barely).