The Disappearing Desktop - It's Real This Time
Geoff Canyon
gcanyon at inspiredlogic.com
Wed Nov 16 20:43:19 EST 2005
On Nov 16, 2005, at 4:42 PM, Dan Shafer wrote:
> Geoff...
>
> On Nov 16, 2005, at 4:16 PM, Geoff Canyon wrote:
>
>> Further, even after universal wireless access, speed can be an
>> issue if large files are involved. As Richard pointed out,
>> downloading 150mb worth of Photoshop each time I want to use it
>> isn't a good idea even at 802.11g speeds.
>
> And AJAX never envisions downloading the application. The app runs
> on the server, the UI runs in the thin client (aka browser) and the
> data is stored on the server and transferred as necessary.
To my understanding, the "app" is the javascript, which _is_
downloaded and runs within the browser. The application logic is
split as necessary between the client and the server. For example, in
Google maps, the code to move the image panes is client-based. This
can be verified by loading a map and then disconnecting from the
internet. The map still drags (but no new images show up). Likewise
the zoom.
A better example is writely, where much more interaction is
available. Create a document and pull the network plug. Text is still
editable, styleable, draggable, etc. The application code to support
this is included in the page itself (about 30k) and several
additional referenced modules, weighing in at 10k-30k each. I don't
know how many modules there are, since writely isn't designed to be
dissected. But much of the "app" is definitely on my computer, and
it's at least >100k.
Parts of it, however, are not. Try to insert a table and writely
displays a nice dialog pointing out that you're trying to navigate to
a new page without having saved your work. The nice little Saving...
indicator has been spinning forlornly pretty much since you yanked
the network.
A better application would be able to save your work temporarily
without having to hit the server. It would also download additional
modules in the background whether you had an immediate need or not.
This is the sort of intelligent download management that a Rev-based
solution could easily provide, and a browser-based solution can't
approach (yet).
>
> Photoshop may be one of the last apps to go this route.
>
> Or maybe someone will find a way to re-factor what Photoshop does
> in such a way that it is even easier than it seems. (I don't know;
> I'm not a Photoshop user.)
Since Photoshop's data files often top out at multiple megabytes, and
you often need to see the whole image to make any change, this seems
like it will wait until faster networks are available.
>
>> Neither is downloading 30 megabytes of Revolution stackfiles each
>> time I want to edit them.
>>
> Again, the notion is not necessarily that these large chunks of
> "stuff" are downloaded. The idea is to create a thin client that
> accesses the information in a clean, elegant, smooth way for you
> while letting everything "big" reside on the server.
I'm not talking about something like Google Maps, where the enormous
data set can be easily parsed out as needed. I'm talking about a
factory management application where there is a ton of program logic.
Obviously this can be mitigated with separate downloadable modules,
but it presents challenges.
>
>> For many applications, local storage is completely necessary until
>> wireless access is 1. Everywhere 2. Really Fast.
>
> As long as we think of apps in traditional terms, yes.
I'm thinking of an app as a thing that allows me to manipulate my
data. Obviously there are also apps that allow me to browse other
people's data. That's what Google Maps is. We'll know that Rev is
being challenged when there are successful Ajax apps that let me work
with my own data. Writely doesn't qualify because it isn't successful
yet.
>
>> I have all of my phone contacts stored on my computer. Some of
>> them aren't on my cell phone (admittedly not many). If my phone
>> contacts were stored on a server and I were someplace where I
>> don't have access to the internet, I have no access to those
>> contacts to look someone up and call them.
>
> I don't disagree that in the absence of Internet ubiquity there are
> such needs. I simply argue that Internet ubiquity is not that far
> off and that we'd do well to be prepared for its arrival.
When it comes to accessing my own data when I want, only ubiquity in
its true sense (universal presence, i.e. out in the desert as well as
here in the city) will do. That's further away.
More information about the use-livecode
mailing list