Off On A Tangent

When I analyze one of my chess games, I fire up Shredder and put it in “analysis” mode, which means shredder just starts thinking about the current position and displays its opinion about who’s winning and what moves it believes are best to make next.  Whenever I move a piece, it quickly brings itself up to speed on the new position.  It’s very handy, because I can go forward and backwards through one of my games and check out what shredder thinks about it at any time.  Furthermore, I also can check out chessgames.com’s opening explorer to check out similar games from their database and see what masters did in the same or similar positions. or 6 year
So what if our computers were running software that constantly watched what we were doing - ie, typing in a blog, and while we did that, continuously “analyzed” it? We’re all familiar with spellcheckers that annoyingly interrupt you to tell you you just mispelled a word.  But what if a background agent started loading up pages found through google using key phrases and words from the blog you were writing?  What if you were writing software code, and a background agent found similar code in a sourceforge CVS repository?  At any time, you could check in on those background processes and see if there was anything of interest.  A code snippet that made your job easier, a web page with relevant information to what you were typing - a blog that revealed you were being completely unoriginal in your own blog.

The more powerful your computer and network, the more powerful these continuous analyzers.  People often ask what we’ll do with the 8-16 procesing cores we’ll have on our desktops in 5 or 6 years.  I think this might something we could use.  Granted, the GUI will have to be clever - right now, if I opened 50 web pages in a browser, either my task bar or my tab bar is going to get extremely crowded.  Such a gui would have to gracefully handle many background tasks and background viewers, letting us easily check in on the agents without cluttering our foreground task.

Every code abstraction that’s new to us is a hurdle we have to overcome before we get any value out of that abstraction.  Douglas Hofstadter wrote an interesting essay I once read but can no longer find that theorized that the reason we experience time as going by faster and faster as we age is because we’ve developed increasingly complex and encompassing mental “globs” of perception that allow us to assimilate more and more complicated ideas and sensory inputs at a glance.  A newborn doesn’t experience “bed” and “car” and “table” and “home”, but rather “darkness” and “light” and “line” and maybe soon “corner”, etc.  Taking in the same raw sensory input but at a lower level of abstraction - it takes longer to “see” things.  As we age, we begin grouping more and more things together, including time related groups, like days and weeks and years.  Our perception of the events of the day include fewer and fewer discrete chunks of larger and larger size, but maybe our subjective feeling of time is linked more to the number of chunks than their overall size.

A code abstraction is similar.  To the newbie (newborn), every method call looms large.  Every link from the current source code file to another source code file feels like “something you have to track down”.  Each class file is new, interesting, exhausting, virgin code to be tediously read through and grokked.  Every javadoc comment that refers to unfamiliar classes feels like a renewal of the dictionary problem of defining words with other words.  But as we learn a system of abstraction, a lot of the feeling of complexity begins to fall away.  We learn that the code we were trying so hard to understand isn’t relevant to an outsider just using the API.  We learn that class X just makes use of classes A-J underneath the hood and we can ignore them.   A set of methods clump together under a perception of common purpose, and the naming convention amongst them becomes part of our unconscious.  Soon the abstractions of the unfamiliar code become our abstractions in our head, and we have learned the lingo - and learned new abstractions that we might use elsewhere in our own code.

But everything new that uses significant abstractions will always seem “over-complicated” and “verbose”, and conversely, everything new that doesn’t use significant abstractions will always seem simpler and less “overwrought” by comparison.  Note that that doesn’t mean everything that’s verbose and over-complicated is using abstraction well, but it does mean that anything simple is not using much abstraction (though of course, there are many things that do not require much abstraction).

Coinjema needs to be able to merge dependencies in addition to simply overriding them. For instance, if context A has a property file, and context A/B also has that same property file, then objects created in context A/B get the properties defined in the A/B property file. It overrides the property file from A completely. Often that’s what you want for most dependencies, but property files are a special beast, and I’ve found I usually want all the properties from A plus the properties from A/B - ie I want the property files merged, with specific properties from A/B to overwrite just the specific properties from A.

I also need it to be able to resolve all kinds of circular dependencies. Right now it does a good job of resolving most, but if you mix dynamic dependencies with static, you can run into trouble. You can also run into trouble if you access a shared dependency from a groovy script file using registry.getSharedDep(), because this also goes outside the “safe” flow of dependency resolution. I’ve looked at this and it appears to be an extremely thorny problem. If Java supported continuations, it’s possible I could solve it that way. Of course, it that’s true, then there’s a way to solve it, I just have to implement my own continuations.

I’m going to need lifecycle control eventually. Doing initialization in the final dependency injection is just not good - causes too many problems. There needs to be a way to re-enter a routine to check for lifecycle needs after dependencies have been set and after the object is fully created, but before it is returned to the caller. Another tough problem. It means coinjema will have to keep track of all the objects it configured in any particular stack, and then go back through them and check for lifecycle needs.

The Java Browser will not be a web browser written in Java. It will browse a peer-to-peer network of mobile java code and data. It will work like a normal web browser, except that instead of hopping from web page to web page via hyperlinks, users will hop from rich gui app to rich gui app via menus and buttons and commands. It will be the undesktop app, with all the power and flexibility of apps that fully live on your desktop, with all the ease and connectedness of thin-client apps.

To work, several things need to be made possible:

1. Transparent download and installation of the JRE. One will have to do an initial download and install of the application and a JRE (perhaps with Webstart’s help), but thereafter, keeping up-to-date with the latest JRE should happen automatically. The JRE should be bundled with the app and should be independent of whatever system JRE might be installed elsewhere.
2. The main container application will be a jini browser that can get proxies from jini services. It will provide a sandbox for jini proxies to run in. The jini proxies will be entrance points to rich apps.
3. Jar dependencies should be tracked per app (per jini proxy) and cached on individuals machines for frequently used applications. Mobile apps will have to have some way of declaring their dependencies (jars and versions) and the container will have to have some means of finding and downloading (automatically of course) those third-party jars.
4. Will need custom class loaders to handle the dependency issues to allow multiple code bases to use differing versions of third-party libs.
5. Mobile code will have to declare their dependencies - not just libs, but JRE dependencies
6. The container will have to require that all downloaded mobile code be signed.
7. Security will have to be set up to disallow use of system resources unless the user allows it, and disallow net connections to multiple external ips, unless the user allows it. Preferably, these permissions can be bundled into a few simple-to-understand settings that allow users to grant permissions easily to the apps they like to use.
8. Would be nice if the container could require that any downloaded code is either open source and comes with the source for inspection, or licensed, such that the creator of the mobile code has bought and paid for a license to use the jini web.

How do we define “the web”? Is it http, the protocol? Is it html, the markup language? Is it the url? Is the browser? The web-server? Some combination? Personally, I think the “web” is pretty well defined by the browser. By the client-side app. It is what displays html, it is what runs the javascript, vbscript, flash, needs the plugins installed in order to work. It’s nice that we have html that all browsers know how to read, but really the browser has grown past just displaying html, and that means, for all intents and purposes, the web has grown past just passing html around.

URL’s are important, and there would be no web without the routers and DNS machines that resolve hostnames and define resources - but then again, DNS is used for much more than just the web, and URL’s are but one way to locate resources - browsers are even now finding new ways. Right now, my browser has a location text box and a google text box. I can type urls into the location box, and I can type nearly anything I want into the google box. I use both equally, but Google is really bringing into question the dominance of a URL view of things. When I can paste an email header into that box and see a visual representation of where that email travelled, or type a phone number into it and get back a name and address of a real person, it seems to me the concept of what is the web is expanding. And it all centers around the user interface of the web browser. The web is whatever firefox says it is.

Which, in a way, is unfortunate, because web-browsers seem limited by their history. Whereas the early web was a page-centric, document-centric, read-only medium, we now want the web to be one remote application after another. That’s what “web 2.0″ is all about - the ascendence of javascrikpt that finally mostly works. And what a piece of crap that is. It’s horrible that the web is being driven by javascript when there are so much better options available.

The problem is more cultural than technical. The browser has gotten itself loaded on all machines - every has one, and finally now everyone has one that mostly runs a fairly standard javascript implementation. But what if the browser was instead a sandbox for real distributable application code (not just static text to be interpreted by a browser) - compiled, full of security measures to prevent abuse, but also enabling automatic discovery of new distributed apps “out there”? Imagine that instead of passing around web pages with embedded javascript, we were passing around java objects, or python code. And instead of a browser displaying a markup language, the distributed code controlled its own GUI fully.

We’d still want browsers - they’re excellent for displaying actual documents for reading and other relatively non-interactive webapps. But foisting javascript onto developers and users for the purpose of making real desktop-like apps that nevertheless use a remote server to supply the database and backend processing is just cruel. It seems unnecessary too - why can’t there be two different kinds of browsers? One that displays the contents of the url network, and another to display the contents of a java jini network? Or another for a ruby-XXX network? Ruby on Rockets anyone?