Well, I think that we can all agree that the idea of a purely portable
desktop environment is a highly compelling one, and that there are many
ways to approach the problem. There is, of course, the VNC approach,
wherein all of our actions are transmitted over the wire in order to
control a remote computer. The problem of having to wait on all of the
network delays obviously leaves much to be desired.
Another way of approaching it is to think of a desktop as a purely logical
construct that can be represented fairly well by, for example, a JSON
object. This will allow us to abstract way the "form" of the desktop from
its "content" fairly well. (What I mean by the "form" is simply the
locations of icons and the locations + sizes of windows. By "content", I
am talking about the actual data in the files that the icons represent.)
All of the form related stuff can be transmitted by JSON blazingly fast,
and the local user will be able to control his/her in-browser desktop
without delay. But the content may very well still be sitting on the
remote server, so double clicking on an icon might result in an
indeterminate delay before the content is fully loaded, depending on file
size and network conditions. But now we can cache the content, and we
won't have to suffer the same delay again... as long as the cache is still
intact, of course.
But even beyond the idea of desktop portability, there remains to crucial
problem of how to locate, retrieve, and render the various bits of
information that are scattered all over the WWW.
In my opinion, all of the past attempts at developing web based desktop
environments have failed because they were, at their hearts, focused
primarily on replicating native desktop functionality by any means
necessary (eg, Flash based desktops) rather than on making actual,
functioning websites more responsive and comprehensible. All of those past
efforts amounted to nothing but curiosities because we just don't need our
web browsers as gateways to hackish, barely responsive desktop
environments. We will always need our web browsers as gateways to the
wild, wonderful, weird place that is the WWW!
As it currently stands, it is next to impossible to reason with the content
that is contained on remote machines. This is because the URL schemes that
we use are fairly arbitrary strings of text. That is, in order to locate a
remote resource, we have to get our grubby little hands on some string that
looks something like
and on and on it goes. To the end user, these are incomprehensible,
indecipherible messes. They only make sense to the backend URL parsing
And even when we are able to locate a remote resource, due to the fact that
the crucial information is usually buried inside of a messy HTML document,
we are often no wiser because of our inability to sift through the layout
markup in order to finally get to the data that we seek.
So in order to inject some sanity into our online experiences, we have to
start thinking about how to allow users to locate the various bits of
content that they are after in much more intuitive ways. And you can't get
more intuitive that icons sitting on desktops and in folders! In this
case, a user is no longer forced to remember a random string of text known
as a URL... all he/she has to do is know what the icon looks like, and in
which folder it might be located.
And power users will be able to reason about remote content using familiar
Unix path notation (/path/to/the/file). They will be able to trivially
write scripts that perform various actions depending on whatever state the
remote content is in (eg current weather or traffic conditions). No longer
will developers be forced to construct convoluted GET requests in order to
retrieve some little bit of information. There can simply be a "file"
named something like "/home/dennis/weather.info" that we can open up by
double-clicking or via script... and now we are enlightened!
I am simply trying to make our web browsing experiences better rather than
making our desktop experiences worse. No one will ever get excited about
offers of desktops that sit in browser windows. But the idea of having the
world at our fingertips from within the context of a familiar, intuitive
interface is something entirely new and exciting! And being able to reason
about the world via programs that are trivial to write is something that
should make all of us programmers positively delirious!!
So the trick now is to get web developers to stop obsessing so much over
serving up full fledged HTML documents, and to start thinking about how to
offer services that deliver compact, essential nuggets of JSON data that
can be delivered into these kinds of in-browser GUIs at blazingly fast
On Tuesday, September 25, 2012 7:36:37 PM UTC-4, Dennis Kane wrote:
> I was thinking of just responding to this old thread<https://groups.google.com/forum/?fromgroups=#!topic/nodejs/bEhSbsm24Y4>,
> in which I talk about the browser based Desktop that I've been working on,
> but the new thing I've been doing for the past week is so superior that I
> thought it deserved a completely new thead. By the way, I know this forum
> place one can go on the web that talks about the client side. Besides,
> with socket.io & websockets... I don't really make much of a distinction
> between client and server anymore. I just know that there's no reason to
> do a document.getElementById() call in node :)
> This new thing is a totally shocking clone of OS X. I knew I was going to
> have to start over from the ground up, because my previous code base was so
> sh*tty, haha! I have really been concentrating on getting a nice, tight
> little API that developers will positively drool over. I don't want to
> make this thing publicly available for many reasons... but you can check
> out a youtube vid (http://www.youtube.com/watch?v=Tq_W19QokXk) that shows
> it in action, and I still have my same old crappy prototype online at
> http://luvluvluv.info. Well, hopefully this is proof that I am able to
> do some cool stuff, and hopefully summa yous will want to start being my
> friend now, LOL!!!
> And get this... the current, uncompressed js file size is only 54kb!