Monday, September 19, 2005

The middle ground.

I've noticed a lot of comments about Google and what they're doing next. One popular idea I've heard suggested is that they're going to try to deploy something to replace (1) Microsoft Office, or other office suites or (2) Microsoft Windows itself, or other operating systems. I won't comment on (2) because it's still a bit too far away. However, I think (1) is possible, but it'll take some work.

The problem is simple: to have an office suite (or any other program), you have to send a lot of program information. Even worse, you have to send fairly complicated information if you want interactivity. I have an exceptionally difficult time imagining someone implementing an office suite using HTML--the pages are inherently static, and you'd have to embed JavaScript to have any level of interactivity. Presumably, this is one of the nice things about Java. "Write once, run anywhere." You could write an office app in Java, send it out, and voila, problem solved. But not quite. Once someone has that office app, then they have it forever, short of deprecation and DRM-like restrictions that get in the way. What they'd want is to provide a service, so no, that isn't it either.

How about X-Windows? That's the ticket! Just host connections to their servers and run the office app from there, problem solved. But we now have new problems. Not everyone runs X-Windows...if you use Linux or Unix, no problem. If you use Windows, then you can either buy XWin32 or download and configure a XWindows program using Cygwin or something. (Note: this isn't so trivial as it sounds...I tried once, but I just gave up and installed Linux for the first time, which ended up being a much simpler solution). Now, they could release a free (cross platform?) XWindows program for people to run their office apps, but that has it's problems too...primarily that it's SOOO slow and unresponsive. I tried to run a visual ANSYS environment connected to a university computer, and the graphics refresh rate was incredibly slow.

So now we're close to a solution, but we're still not there. We need a middle ground. Something more flexible than html, but less flexible than XWindows, and won't run without an internet connection. (Yeah, that last bit might seem restrictive, but since Google's prime choice is web services, it wouldn't make sense to provide services that don't require the web.)

Let's see now...we all use html, and a web browser to view it. The computer doesn't have to transmit the shape of each letter, it just says "this letter in this font and this size" and the browser takes care of the rest. Why not have another markup language for applications, and use a different kind of browser to view things with it. The browser would be responsible for "common" features like menus & menu bars, child windows, standard icons, panes, messageboxes, and even common controls like sliders, buttons, treeviews, etc.--the basic stuff that we expect a variety of programs to have. However, the business logic is all done by the server. When the Application Browser connects to a remote application file (.raf), the browser receives enough information to populates its menus, bring up the default screen (maybe with a logon request?), and establish a working (non-static) connection with the server. When a menu is opened, it responds immediately (because menu processing happens on the local computer), but when a menu item is selected, a corresponding request is sent to the server (except for, say, menu/toolbar customization request). The processing is handled remotely, and the screen is updated appropriately. The only significant source of lag is if an image or graph is being displayed, like when someone performs panning on a map or zooms in on a chart.

The nice part of all this is that a minimum amount of information is sent to the users computer. Just a little text here and there, and the Application Browser knows how to do its thing. I must admit, one of the best things about this approach is that since the information is reduced to only its critical text-based components (except in image loading), the use of Lisp is greatly rewarded. I'm familiar with what Paul Graham did with Viaweb over or about 10 years ago--he basically used Lisp to not only serve up web pages but also allow the easy creation of said web pages. I've found that the reason he could do it was because he was working with a small, well-defined output format: HTML. It was static, simple, and no one expected much of it. This was before Ruby on Rails, flash, and (I could be wrong about this one) JavaScript. Interactive web pages were not required. Because he had a limited playing field, he could easily manipulate it as he needed using ONLY text files. Now, technically, someone could come along and write something in Lisp that outputs JavaScript and html, but seriously...using a programming language to write code for another programming language? That's kinda crazy--it's way more sane to write an programming language that produces output in a certain standard protocol. What we need is an Application Protocol. Something that allows us to express (in text) the basic interactions of software between the server and the user, without being bogged down in details (like getting the menus wide enough to accommodate all their entries).

Also, because the developer is hosting the program, access to the program is under control of developer, as well as updates and bug fixes.

Bottom line, html has outgrown its shell. These things like JavaScript are patches that emulate interactive web pages, but the bottom line is, they're still web pages. Web programs, on the other hand, seem to have a future. Unfortunately, it doesn't look like there are many (any?) protocols in place to handle this. I could be wrong...I still have to look at J2EE closer, and maybe CORBA ORBs. They might provide an answer, but I'm still learning.