Coinjema Features

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.

What a Jini 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.

Defining the 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?

Smarter Software vs Easier-To-Use Software

I often encounter a trade-off in my coding between making my code smart vs making it easy, or transparent, to use. A simple-to-understand API is often a dumb API that makes you tell it what to do every step of the way. Smart code doesn't require that you tell it as much, but it often takes more work to understand how to use it properly.

But I think smart code that has earned my trust is the most joyous code to use. It may have taken time to learn, and it may still bite you in the ass with unexpected behavior, but when it works, it saves time and coding. Tedious simple API's may be more robust, but does all programming have to revolve around correctness and robustness? What of fun and challenge? Sometimes it's better if our programs actually interest us.

We're All Platonists

In an interesting article on TSS (Spring 2.0 vs. the Anemic Domain Model), a lot of software developers fought over what makes a cake a cake. It sounds silly, but it's something OO purists fight a lot about - what belongs in their classes and what does not. Specifically, in this case, the question became, "does persistence logic have any place in the domain object classes?" In other words, should your Cake.class have "save()", "delete()", and "update()" methods?

OO programming makes us all Platonists. We stare at the shadows on the wall and try to decipher the true form of Cakeness. Does a cake bake itself, or does the oven bake the cake? Or does the oven just heat stuff, and the cake batter reacts to heat by forming a cake? The shadow silhouettes on the cave wall are less than clear, but we try our best to make our Cake class mimic the true Platonic ideal of Cake. And so we argue and fight about cakeness.

But Platonic forms are problematic. Where you draw the boundaries around your objects and categories is always an arbitrary decision. But more importantly - does it even make sense to consider anything in our system as representative of a Platonic ideal? As programmers, we usually treat our classes as definitive - the ideal form, if you will. The web page where users edit objects is the cave where the shadows play. Understanding the Java ideal from the web page is impossible - it is a mere shadow of the ideal Java class.

But, we could easily take a more database-centric view and consider the data in the rows and columns to represent the true Cake object. The Java class now becomes the shadow puppet, and the web page a description of the shadow play to a blind man. In all this, there is the unstated assumption that something in our system represents the ideal Cake form.

But consider - at any future date, a new client app could come along with a different implementation of Cake. It could read the same data from the database, but present completely different behavior and a different web page or other GUI to its users - effectively changing completely what it is to be a cake. It would make the data its slave rather than vice-versa. So is the Cake in the database or anywhere in our code? Or is it still in our heads? Maybe there is no ideal Cake form - maybe we programmers can learn something philosophy figured out hundreds of years ago - there are no forms, only our concrete implementations.

The upshot would be that software design decisions and arguments wouldn't be concerned with creating a pure and correct ontology - they would concern themselves with the pragmatics of programming - clarity, performance, flexibility, modularily, etc. If "cake.bake()" and "cake.save()" make sense from the vantage of such practical design concerns, then declaring "cakes don't bake themselves" is meaningless. We should let the wisdom of philosophy inform our programming: there is no ideal cake, there is only what we bake.

And maybe programming can inform our philosophy as well: the shadows on the cave wall aren't "mere" silhouettes of their ideal counterparts. The shadows enhance the static ideals, and the description to the blind man improves with every retelling.