ILU is a very promising technology for tying the web to object oriented programming. The more I see, the more I am convinced it will work. Here's why.
The heart of ILU is ISL, the Interface Specification Language. Application protocols are specified in this language. Once specified, they can be checked and implemented to a large extent by machine. (Combined with Larch, they could be further specified and checked.)
We have to be careful with an interface specification to be sure things don't get too rigid. Loosely structured message formats like RFC822 allow tremendous extensibility. But ILU has a number of extensibility pivot points:
Not only is the interface specification language independent of transport, message format and implementation language, but the runtime architecture explictly provides an API to slot them in.
The clean, modular architecture and the unrestricted copyright mean that development resources from all over the net can be applied to the system.
Much of the work on enterprise object systems is done in the context of the CORBA architecture. The vertical markets (e.g. manufacuring, medicine, ...) seem to be hammering out their specs in the OMG forum. This makes CORBA support very valuable.
CORBA's IDL can be translated to ILU's ISL with a few exceptions:
It's straightforward to write specs in CORBA IDL that translate nicely to ILU IDL. But it's not clear how problematic it is to translate specifications written without ILU in mind. I'd like to know whether existing IDL-based specs like OpenDoc and Fresco can be tranlated to ISL, or whether they violate some of the above constraints. (CORBA security uses ANY.)
ILU 2.0 will be one of the first IIOP implementations -- almost certainly the first free one. I don't expect IIOP to be used over the public Internet on a large scale -- I hear it doesn't address high latency, low bandwidth conditions very well. But I do expect lots of LAN and enterprise object systems to support IIOP, and interoperability there will be critical.
Administrators of large firewall systems generally require publicly reviewed source code. ILU has it. These admins actually need source to implement their local access control and accounting policies. Access control support is already in ILU, and I expect to see a lot of effort on instrumenting the ILU runtime for auditing (logging). There will be standard policies supported, and the possibility of hacking local policies will be there.
ILU makes all sorts of gateways and interoperability mechanisms nearly trivial. You want a gateway that translates between SunRPC and CORBA IIOP? Just link both transports and message formats into your server, and you're done. Eventually, I expect the same will be true of DCE, HTTP 1.x, IBM's DSOM, Microsoft's DCOM, etc.
This will be critical when you want to run HTTP-NG from your palm-top, across a serial link to your PC, across the LAN, through the firewall, and over the Internet, then back through a similar set of twisty passages to the server. No single message format and transport will be suitable for the whole route.
And ILU's explicit support for asynchronous calls makes streaming and batching (and generally minimizing round-trips) straightforward.
If an ILU-based HTTP-NG addresses even a few of HTTP 1.x's limitations, the market demand will be sufficient to drive the development and administrative efforts.
Then, the distributed OOP community will have its foot in the door: the ILU runtime will be widely deployed. Since any number of application protocols (interfaces) can share the same TCP connection, deploying new APIs over the same transport will be simple and straightforward. They can probably even be bootstrapped at runtime, when combined with mobile code technologies like Java (firewall policies might cause restrictions, but...)