RE: Quixotic thought #57: Software salvation via JCSP

[tjoccam@xxxxxxxxxxxxx (Lawrence Dickson)]

All,
   This is fine brainstorming. So far proposed: Roy Wilson's robust CSP
web server; John Campbell's all-CSP wireless phone. What people should
do is form teams and start mapping out the design of these things as if
they had a budget.
   Here's mine:
   The universal block storage device. It wraps around generic storage
(starting with SCSI disks?) running as an occam process with a universal
asynchronous channel-based communication protocol (I think something
like this was once done with Transputer code) and enough state for quick
and total control and error response. Because it's an occam process it
can be soft-simulated, nested etc, making RAID easy (my workplace has
just been through THOSE wars with standard drivers). Start with X86 or
other platform of choice, go on to specialized hardware maybe. The
definition of block storage is extremely simple, but the current
driver, kernel, buffer based approach to it has become a nightmare of
stiffness.
   Comments on other ideas...

> Message-ID: <EB509ADC624AD111B2AA00A0C9786242037E9CD2@xxxxxxxxxxxxxxxxxxxxxxxx>
> From: "Campbell, John" <John.Campbell@xxxxxxxxxxxxxx>
> To: occam-com@xxxxxxxxx, java-threads@xxxxxxxxx
> Subject: RE: Quixotic thought #57: Software salvation via  JCSP
> Date: Fri, 20 Oct 2000 16:11:32 -0600
>
> Hi
>
> Summarizing, the idea has been tossed around that a
> demonstration product would "prove" the merits of CSP
> to the world:
>
> > the possibility of persuasion by developing the kind of "product" for
> > which there is already widespread interest.
>
> Here's my own idea of the ideal demonstration: a wireless
> telephone, implemented entirely in one high level language,
> (either occam or java), both hardware and software.

This will require some preparatory work, essentially modeling the
requirements (hopefully a very general communications module) and
building language/tool requirements around it. Remember the Transputer
configurer...? That need was always a stepchild in the old days.

> The
> hardware should be asynchronous.
>
> This would generate interest from a number of communities.
> Telecom is hot right now. Seamless integration of software/hardware
> would get the attention of the co-design crowd.  Asynchronous h/w
> design is considered difficult, is very quiet (no clock synchronization)
> and low power.  CSP based design could unify it all.  Maybe with Adrian's
> Continuous CSP, you could even do the analog design.
>
> Think of it! The entire design in one language...OK, so I'm a dreamer.
> -jc
>
>
>
>
> Someone already mentioned
> > Quantel: my speculation (again) is that a webserver shown to be
> > deadlock/livelock-free on empirical and mathematical grounds would
> > attract more interest and lead to diffusion of CSP-inspired design
> > doctrine and JCSP-based design methodology. The members of this group
> > could accomplish such a task, though it might require a more
> > collectivistic orientation than many are used to, or
> > comfortable with.

The key thing is to define the project in such a way that it is clearly
finite. The discomfort comes from infinitely extended unfunded work
commitments.

> >
> > Roy
> >
> > --
> > Roy Wilson
> > E-mail: designrw@xxxxxxxxxxxxxxxx
> > http://members.bellatlantic.net/~designrw/index.html
> >
> > >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
> >
> > On 10/20/00, 9:58:06 AM, M_Boosten
> > <mboosten@xxxxxxxxxxxxxxxxxxx> wrote
> > regarding Re: A path for CSP-based:
> >
> >
> > > Hi all,
> >
> > > topic: ...introducing CSP in industry...
> >
> > > Quite a while ago, Andrew wrote:
> >
> > > > So: unless you get in at the start, the (perhaps apparently
> > > > insignificant) costs of transferring are simply too high.
> >  In an ideal
> > > > world CSP would be a nice refinement to our development
> > process, but at
> > > > the moment there are more pressing needs.  Perhaps that is worth
> > > > remembering - you're not introducing CSP to people who
> > have nothing to
> > > > do all day, but to people who already have a stack of
> > good ideas that
> > > > need trying out when there's time available.  Busy busy
> > busy.  So no
> > > > more emails from me ;-)
> >
> > > I agree, this is one of the main problems of introducing
> > any new idea,
> > > including CSP.
> >
> > > Cheers,
> > >       Marcel

Just being able to describe in full these products in an "occam
configurer" syntax would get you most of the way there.

Larry Dickson