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 "http://www.somedumbdomain.com/stupidpage?crazy_param=flux&dumb_arg=spam&weird_sid=Gjsk3MKs5hsgf6jeO7Iwjn8YUKs";, and on and on it goes. To the end user, these are incomprehensible, indecipherible messes. They only make sense to the backend URL parsing algorithms. 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 speeds. 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 > is all about server side Javascript, but there is not really any serious > 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! > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
