JCSP, CSP Networking, and other some other points

["Chalmers, Kevin" <K.Chalmers@xxxxxxxxxxxx>]

All,

This email is going to cover a few different points so bear with me a little :)

First of all JCSP.  I have had a couple of emails recently asking about progress with JCSP and with one thing or another we haven't had much time to work on updating the core JCSP package.  We have discussed possibilities of taking JCSP to a Java 1.5/6 version, and utilising various parts of the Java API to simplify / increase performance, but I don't think any concrete decisions were made.  So my first question is really about where we should be taking the core JCSP package?  What sort of functionality are people looking for that we don't yet support?  I am, finally, going to try and put various JCSP versions / packages up on the repository, including an updated JCSP Micro Edition and Jon's JCSP Robot Edition.  Possibly Groovy, but that's a discussion point I feel, as it is not really Java as such.

Secondly, and probably most important from my point of view, is CSP Networking (for want of a better term).  As some of you may know, I have been working on a generalised protocol and architecture for JCSP, which we can re-implement on the various CSP platforms/frameworks (occam, C++CSP, PyCSP, etc.), and thereby gain some form of inter-framework communication.  We are still very much in an early stage, so this is sort of general call out to interested parties who would like to either contribute some insight, or, even better, help take things forward.  I am currently working with John Markus in Tromso (when I can) to try and get PyCSP and JCSP to interact.  So far I have JCSP sending strings to Python, and Python acknowledging and sending back a reply, so we are making some progress.  At a quick count, we have seven frameworks probably looking at having some network functionality (JCSP, PyCSP, occam, Transterpreter, C++CSP, Haskell CSP, CSO (Scala)), and it would be pretty good if we could get an Erlang version as well.  I am hoping to start a project with this, so as time goes on we can set up the various resources that we need.

Related to this request is a question on a C/C++ reference library for the protocol and architecture.  I am currently thinking about the best method to go about having a standard native library which each CSP framework can essentially hook into, thus reducing the overall maintenance / development work.  To simplify the description of the architecture a little, essentially there are a series of queues (infinitely buffered channels) which receive messages for incoming network channels, and TX/RX processes to handle network comms.  When it comes down to it, there is nothing that essentially requires CSP semantics within the architecture (there is no synchronisation between the TX/RX processes and the networked channels as the channels are infinitely buffered), and any shared state can happily be protected within a standard critical region.  So currently I am considering two different approaches:

1) Use C++CSP to develop the library, which requires C++CSP and Boost.
2) Use Intel Thread Building Blocks.  Only requires one library.

The last time I talked to Neil, he was unsure if C++CSP was 100% Windows compatible, and also I would have to strip out the existing C++CSP Networking functionality, meaning it wouldn't be an exact version.  TBB I'm not as familiar with however, so if anyone knows any problems with the library let me know.  If you have any insights into either it could be useful also.

Cheers,

Kevin

Kevin Chalmers,
Lecturer,
School of Computing,
Edinburgh Napier University,
Merchiston Campus,
Edinburgh, EH10 5DT

t: +44 (0)131 455 2484



Napier University is the best modern university in Scotland* and number one in Scotland for graduate employability**
(*Guardian University Guide 2009)
(**HESA 2008)

This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else out-with the University without the permission of the sender.
It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Napier University does not accept liability for any loss or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the University's system is subject to routine monitoring and filtering by the University.
Napier University is a registered Scottish charity. Registration number SC018373