There are a lot of areas where AsyncScala could be improved. And this document describes some planned
Note: That I'm developing this project on my free time, and my day job is completely unrelated to this project.
So progress would be somewhat slow. I would also consider contributing code to some bigger project to speed
General Improvements and Core Library
The focus of the current version is to demonstrate usability of
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
- Better integration with Scala Actors. The currently the way to receive the actor events is simply
Other way is needed. Possibly use some actor even stream that reads non-vat related events from actor event
- 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
- 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
- Figure out how to insert syntax highlighted code snippets in the generated documentation. Maybe to switch
to other document format.
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
- 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.
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.
Beyond the Planning Horizon
There are some features that I would like to do, but which are currently beyond the planning horizon. So they
are unlikely to happen (unless I get some library related job ;).
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
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
- 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.
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