General Improvements and Core Library

The focus of the current version is to demonstrate usability of E's approach to building asynchronous applications. So it was attempted to get basic things right and to disregard many other issues that are required to bring this library to the production level.

• Performance tuning is needed. In most cases the simplest approach that works was used.
• Visibility of classes, objects, and members should be double checked. Currently it is sometimes wrong in the both ways. Some members are over restricted, other ones are too lax.
• Using more Scala-features to make better API. I practically began to study Scala while doing this project, and I'm still learning new Scala features (partial function was the latest that affected core API). So in some places there is some rough edges because of this. Suggestions are welcome.
• Refactor TaskTree to be more generic. It actually should use AllForBuilder and AllTupleBuilder for its forks.
• Better integration with Scala Actors. The currently the way to receive the actor events is simply horrible. Other way is needed. Possibly use some actor even stream that reads non-vat related events from actor event loop.
• Port the method Promise.willBe[T](class : Class[T]) : T that creates proxy wrapped over promise that is able to accept events for the object to which the promise will resolve in te future. When promise is resolved, it dispatches all pending events to resolution. The method was available in Java version of the framework, and its implementation was quite straightforward.
• Use ASM to generate proxies for the objects. A pluggable ASM code generator was available for Java version of the framework. Possibly it should be supported for scala version too. It just need to be ported.
• Possibly merging Java, Scala, and Groovy versions together. In future it might be considered to merge these versions together, so they would some common parts like promises, outcomes, and some base services like NIO, object proxies, vats, etc. But DSLs for control flow will be different for each version, since each language offers own means. The languages will be able to interact using standard component model and promises.
• Figure out how to insert syntax highlighted code snippets in the generated documentation. Maybe to switch to other document format.

Stream Library

Stream library was created on almost one day after watching one presentation on RX. And its scope is practically is limited to almost me-too single demo. In future, the following is planned for the stream library.

• Mine RX and similar libraries for more ideas.
• More utility methods on rich objects and more rich streams.
• Swing event streams, possibly integrating Scala Swing library.

NIO Library

In future, NIO library is planned to be improved in a number of ways (if I will have time for it):

• Java 7 version over asynchronous channels from NIO.2 (it will be actually simpler in that way, and non-blocking File IO will be finally supported)
• More utility methods and classes (for example buffered streams)
• Non-blocking SSL support
• Integration with other libraries like Apache MINA
• Protocol library with support of BEEP and HTTP.
• Refactor some simple and reasonably licensed StAX XML parser and writer to be non-blocking (to provide XML events as a stream). Considering that AsyncScala code looks almost like normal synchronous code, this should not be too difficult.

Distributed Computing

There is no yet support for distributed computing. This important aspect and some work should be done to carefully optimize the project for the distributed environment. There are some places where to still ideas from.

Compiler and Language Extensions

Other important topic is that it is possible to greatly optimize the code, if the compiler is extended. So it might make sense to discuss it with scala compiler group. The following wonders are possible with language minor extensions while keeping all usability benefits (guided CPS rewrite).

• Greatly reducing amount of created promises. This is at least 4 less objects on each asynchronous method call.
• To have efficient trace backs, so stack traces could be used again for asynchronous case.
• Asynchronous and reliable tail recursion with natural syntax (now one has to pass resolver explicitly, and it easy to forget resolving it in case of failures).
• Greatly cut on amount of messages passed around (conservative estimation 70%)

Such language extension could be used for other purposes as well for DSL construction.

Persistent Evaluation

What language does looks very similar to what BPEL-containers what to achieve. The only twist that BPEL provides persistence, and it is difficult to make automated persistent when there is a zoo of compiler generated closures. An interesting venture might be compiling AsyncScala-like DSL to database-based processes.

This would make business integration tasks simpler. For start, there might be even XML based language based on composition of persistent asynchronous operations. The idea certainly look tasty, and I'm thinking about it.