RE: csp as database query language

["Stephen Maudsley" <Stephen.Maudsley@xxxxxxxxxxxxxxxxxxxxxx>]

-----Original Message-----
From: Stephen Maudsley [mailto:Stephen.Maudsley@xxxxxxxxxxxxx]
Sent: 14 March 2003 19:08
To: occam-com@xxxxxxxxx
Subject: RE: csp as database query language




-----Original Message-----
From: Campbell, John [mailto:John.Campbell@xxxxxxxxxxxxxx]
Sent: 14 March 2003 17:52
To: occam-com@xxxxxxxxx
Subject: csp as database query language


Dear All

The mindset of most people using CSP (or manifestations
of it like OCCAM) is to write programs to *make* something
happen.  I've been thinking the last few days that there
might be a useful alternative interpretation.

It seems to me that you could write a CSP description of
a *hypothetical* process that might be at work in a large
data base.  You could do a probablistic analysis to see
how many matches you'd expect in a random system, and
test the csp with the real system to see actual matches.

Thoughts anyone?

###########################################

I'm not sure I fully understand what you're saying but ignoring that...

What you're describing sounds similar to some aspects of the design of the
Assayer network instrumentation system.

Assayer assumes that the universe is made up of communicating processes. If
you want to reason about its operation then you could take all of the
processes descriptions and think about them. However in the real world
either nobody has written such descriptions or even if they have they
wouldn't give them to you. In fact if you view these processes as black
boxes then you can't see the innards anyway and can only measure the
external behaviour (this was vaguely behind my rambling chat with Peter a
while ago).

So you can't measure logic, only state and logic must be inferred.

So assayer is a loosely coupled set of probes (which have a semantics) that
dump measurements into a database (SQL at the moment). Now, those of you
still awake will realise that the sequence of measurements from each probe
is a trace and will have a relationship with the other traces collected that
can be defined by a CSP description.

In practise, not everything is usefully thought of in that way.

For example, you can think of user interactions with digital TV receivers as
processes with state which interact with a local process which interacts
with processes running on a J2EE server. But a lot of the J2EE pathologies
(like running out of bandwidth) are best thought of as completely
asynchronous mathematical functions.

I'm rambling... is this where your thoughts were heading?