RE: JCSP, CSP Networking, and other some other points

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

Nothing within the core underlying functionality will change (unless Peter adds anything).  We are really talking externally.  For example, typed channels shouldn't be a problem and would utilise the existing channels underneath.  Library wise, we can consider support for Swing (AWT is old), etc.  Don't think of this as a modification exercise, more an extension.

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

t: +44 (0)131 455 2484



> -----Original Message-----
> From: Andrzej Lewandowski [mailto:lewando@xxxxxxxxxxxxx]
> Sent: 24 February 2009 12:38
> To: Chalmers, Kevin; java-threads@xxxxxxxxxx; occam-com@xxxxxxxxxx
> Subject: RE: JCSP, CSP Networking, and other some other points
> 
> " 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.."
> 
> DON'T FIX IT IF IS NOT BROKEN. First of all.
> 
> A.L.
>
> -----Original Message-----
> From: Mailing_List_Robot [mailto:sympa@xxxxxxxxxx] On Behalf Of
> Chalmers,
> Kevin
> Sent: Tuesday, February 24, 2009 4:04 AM
> To: java-threads@xxxxxxxxxx; occam-com@xxxxxxxxxx
> Subject: JCSP, CSP Networking, and other some other points
> 
> 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
> 
> 
> 


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