Build system
JOLIE's SVN contains now an ant-powered build system that compiles all the protocols, extensions and libraries and then is able to install the resulting runtime environment in your computer in a painless way. Painless like "just type sudo ant install in trunk/ and you're done".
The system is still beta-ish, but it's been tested by some people other than me. So now installing JOLIE from SVN is just:

svn co https://jolie.svn.sourceforge.net/svnroot/jolie/trunk
sudo ant install

Warning: I still have to implement ant uninstall, so you'll have to delete /opt/jolie and /usr/local/bin/jolie by hand for uninstalling it.

If you want to control the install directories, just edit the buildconfig/config.properties file, it's short and easy. Suggestions and reports on the build system topic are very welcome, so please tell me of anything comes up to your mind / bugs you find.

You'll notice a couple jars in the SVN, they're there because you probably don't have them in your system and they're usually not packaged by distros (e.g. Google Web Toolkit servlet jar, relaxngDatatype). It's Java, so recompiling them is useless. But if you want to use _your_ jar anyway, just change the library paths in config.properties.

Program checker upgrades
The JOLIE pre-execution program checker now punches you (emits an error) whenever you're trying to use the wrong communication pattern (you send a message, but you don't wait for a response when you're supposed to, or vice versa, etc.).

Concurrent request-response pattern performing in persistent channels
Whoa, this paragraph title is so long and confusing. Let's look at the problem by using an example: if you use the same, persistent socket with multiple threads (say, 2 threads) for performing a request-response pattern (i.e. you send a request and you receive a response back, like in HTTP), the messages risk to get messed up, because now when you get the first response you aren't sure which thread is expecting it.
HTTP pipelining solves that problem for you by sending the responses in the same order as you sent the requests. That implies that you must first send all your requests and then wait for all the responses. But in a true asynchronous system, you'd want simply to be able to send and receive things without introducing such slowing factors.
How does JOLIE solve that? We tag each request with an identifier and we require the response to equip the same tag. That way we can relate responses to their requesting threads. The internal handling of this is complicated, but it's all abstracted away at the language level... the programmer doesn't even need to know this mechanism.
In-memory communications, Java<->JOLIE channels and the SODEP protocol already support this new feature. We're currently thinking about possible solutions to introduce this on other protocols.

Website and documentation progress
The new website works are on schedule (i.e. we should publish it by this month or at least december, no later). We have tutorials (Claudio already made a lot of work.. my schedule fixes next week for full diving in user documentation writing), examples (I'll problably publish some of them in advance on the blog) and so on.
A lot of in-code documentation has been polished up (especially in the support libraries for external programs interacting with JOLIE).


Mmmh I estimate a 50% rate of things I forgot to report... I should probably post more. ;)