x++ beta 0.2.2 continues various additions to the x++ language. These additions support the invocation of external library executable functions. For example, an x++ program can now invoke a regular Windows .dll's functions no matter what language the .dll is written in. Details can be found at:
http://xplusplus.sourceforge.net/Lex/xppextlib.htm
In addition there is support for x++ services. These are web services implemented using HTTP, XML and x++. Of course x++ is XML and so this is natural. The good news is that there is not a whole lot of x++ that one needs to code in order to invoke web services this way. Also there is not a lot of work that has to be done to publish your x++ services. Details can be found at:
http://xplusplus.sourceforge.net/Lex/xppsrvc.htm
It is also possible to create courier messengers. These are x++ objects which can be sent to execute complex code at a remote machine. This is a way to reduce network traffic in messaging because if there is an error then the courier object can handle it at the remote site. In that case it may then execute something else. At the end of the whole mission the result(s) will be sent back to the source machine. This is what I think is a better way of doing web services than the form we hear of frequently nowadays; i.e. simple messaging.
In all of these x++ service implementations, since x++ is XML, it is possible to implement an x++ services client without using the x++ interpreter! All that the client needs to do is to be able to put together the appropriate XML in a string and then do an HTTP POST to send the XML to the remote machine. Then wait for the result and it will come back. This works for simple messaging as well as courier messaging. So you can do this in C++, Java, Visual Basic, etc.
In addition to the above, there are some changes to Templx, the x++ IDE, that allow for easier keying in of x++ programs.
Further work to expect in the coming months is an alternate syntax for x++ which will be free form text based. It will look a lot like the C family of languages. The reason for this is to support the needs of those programmers who find the XML format of x++ programs difficult to read and write. The text and XML representations of x++ will be two-way translatable and the x++ interpreter will execute the code in either form.