RE: JCSP Advice anyone?

["Ruth Ivimey-Cook" <Ruth.Ivimey-Cook@xxxxxxxxxx>]

Jim,

> I agree with Bernhard that you should take a look at the call-channel
> concept - the only problem is that its a bit long winded to put
> together.

I agree :-(

> Ideally I wanted to extend the Java syntax in our (the now
> expired Quickstone) JCSP compiler to do this much more simply, but we
> had to stop work on it before we got that far.  We did however write a
> rather cool Java app to support code generation of complex call channel
> servers in bulk, but I'm not sure how much use that'd be to Ruth as it
> outputs Java.

As I've indicated to Bernhard, I found the learning curve for call channels
steeper than I was happy with; I may well have another go sometime.
 
> Another approach that might be worth considering is creating a call
> channel interface using a proxy object in a similar way to the Hibernate
> database library. Java Proxy objects allow you to dynamically create a
> Java interface and respond to method invocations pro grammatically.  I

I'm afraid I don't know Hibernate DB or Java Proxy objects.

> don't even know if C# supports this, but I'd be surprised if it didn't.

C# is actually a very simple language; there's C++ stuff that's not in C#.
For example, no multiple inheritance, there are no "bit" types or unions.

At a guess, a proxy object might map onto an Interface variable? That is, a
variable of type "interface I"?

> It does however depend on how bothered you are about efficiency.  It's
> also a bit complicated - but more fun :).  If you're feeling really

I'm afraid complicated == more chance of failing == not going there. There
are too many risks to this project already :-(

> adventurous you could use reflection (and possibly method annotations)
> to generate the necessary classes/interfaces statically at build time,
> which would get around the efficiency problem...

I'm concerned about efficiency in some areas - communication, for example,
but not others. It depends. I suspect efficiency is moderately important in
this area.

> One thing that'd might make things easier (i.e. less long-winded) might
> be to write a class that extends CSProcess that just takes a delegate
> and calls it in its run method.  It'd then be easier to create processes

How would you use this?

> with less code - I have to admit I haven't fully thought this approach
> through as I'm not really that familiar with delegates.
> 
> Also remember that you don't have to use Parallel or ProcessManager at
> all if it's a real pain, you could just start threads in the normal C#
> way - the CSP synchronization operations will still work.

That's good to know!

Regards,

Ruth