[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ICoTec
Peter:
> We really need a new name for the extended occam language! Just try
> getting anything on "occam" past research council reviewers or panels.
Name: Integral COmponent TEChnology
ICoTec
Slogan: "Enabling Compositional Component Development"
Arguments:
- Points at Business impact (components are still hot)
- Name and slogan point at benefit
- It's not just a language, it's a technology
- If you look at it like: "IC-o-Tec"... you read: it uses
similar concepts as Integrated Circuits, in which
componentization has proven its Business Relevance
gloriously. This last argument is important to convince
managers (decision makers in companies), simply because
it's their one and only argument why software components
should also be integrateable. From managers, I hear this
argument regularly, and I do not believe it to be (completely)
true, using the current state-of-the-art in Microsoft
technology as the basis. CSP based technology contributes
seriously in this respect.
Hope you like my reasoning... hope you like the name...
Cheers,
Marcel
Marcel Boosten | Philips Medical Systems
System Designer 3DRA | Room QJ1301
System Design | P.O. Box 10000
Cardio Vascular Development | 5680 DA Best
Marcel.Boosten@xxxxxxxxxxx | The Netherlands
Phone: +31-40-27-69019 | Fax: +31-40-27-65650
To: ianeast@xxxxxxxxxxxxxxx
java-threads@xxxxxxxxx
occam-com@xxxxxxxxx
philippe.lemaire@xxxxxxxxxxxx
"P.H.Welch" cc: P.H.Welch@xxxxxxxxx
<P.H.Welch@xxxxxxxxx> (bcc: Marcel Boosten/BST/MS/PHILIPS)
Subject: Re: No message for 6 months
03/06/2003 17:46
Classification:
> Have heard nothing re CPA 2003...
This was fixed ages ago - sorry, about time we announced it!
CPA 2003 will be on 7-10 Sept, 2003, at the University of Twente,
the Netherlands. Our hosts are Jan Broenink and his team.
Jan is setting up the web site for CPA 2003. Meanwhile, I am told
we will be at the conference hotel on the university campus - and
it looks really neat:
http://www.drienerburght.nl/english/index.htm
CPA-2003 is a week earlier than last year's meeting. I suspect
that submission/notification/camera-ready deadlines will therefore
be brought forward also by one week - i.e.
Submission of full papers: Monday, 2nd. June
Tutorial / workshop proposals: Monday, 2nd. June
Notification of acceptance: Monday, 30th. June
Camera-ready copy: Monday, 14th. July
But these dates have to be confirmed.
> Ping ...
Well ... there's lots going on at Kent, :). Too darned busy with
teaching and chasing money though to communicate :(. On-going:
o KRoC - the Network Edition (with similar facilities to
Quickstone's JCSP Network Edition - www.quickstone.com);
o mobile *processes* for KRoC occam;
o semantics for the above (another CSP extension);
o continuing niggles over the semantics of PRI ALT!
o KRoC channel commstime down to 16 nanosecs (on a 3.06 GHz. P4);
o Raw Metal occam eXperiment (RMoX) - a native all-occam OS and/or
embedded system harness for self-booting raw occam, currently
limited to i86 processors. No underlying Linux or Windows.
32 priority levels. Interrupts mapped to channel communications.
Interrupt response times in nanoseconds. Memory protection
for untrusted utilities (e.g. C programs). All-occam network
driver processes. The software architecture makes heavy use
of mobile channel-ends, reported at CPA 2002 and introduced
in KRoC 1.3.3;
o oDoc - an occam html-generating documentaion tool, similar to
javadoc. This highlights a real need for some formal library
mechanism - where "formal" means built into the language.
IMPORTANT: does anyone have a proposal for such a library mechanism?
Ours is loosely based on Java packages. Is that a good idea?
o upgrading the public JCSP release to Quickstone's many improvements;
o oGraph - another attempt at a GUI/graphics toolset for KRoc. This
time, we're not using TCL/Tk or the GIMP toolkit - neither of which
were totally robust when misused the highly concurrent way required
by occam. All widget/graphics code (above X primitives) has been
locally generated - thanks Fred (who has nearly written up)!
o C++CSP - a JCSP-like API for C++, with an occam/CCSP-like fast kernel;
o occam -> JVM compiler: write in occam / utilise any Java library.
Credits: Mario Schweigler (KRoC-net), Fred Barnes (everything, of course,
but especially mobile processes, faster KRoC kernels, RMoX and oGraph),
Christian Jacobsen (RMoX, other mobile channel experiments), Jim Woodcock
and Ana Cavalcanti and Alistair McEwan and Xinbei Tang (semantics and
Grand Challenge applications), Ramsay Taylor and Adam Sampson (RMoX),
Jonathon Stott (oGraph), Peter Maley (oDoc), Neil Brown (C++CSP),
James Bielby and Tom Shackell (occam -> JVM) ...
Will post something soon about why channel *ends* are so important and
why we are changing (actually have changed!) occam and JCSP to enforce
this point. Yes, we are dictators ... but we try to justify ...
================================
MOST IMPORTANT OF ALL - PROBABLY
================================
We really need a new name for the extended occam language! Just try
getting anything on "occam" past research council reviewers or panels.
It only takes one to black-ball. Example: from two rather famous UK
Computer Science Professors reviewing the above research (without
reading anything published about it) - "the work of this research group
is focussed on old technolgy (CSP and occam) ... they need to change
the focus of their work". Yes, sir.
So, come on folks, we need a new name so that there's a better chance
that uninformed prejudice will not autonmatically be invoked. Make
them read something to realise what is being proposed!
Previous suggestions:
occam-M (mobile occam) [guess not ... sigh ]
occam-D (dynamic occam) [ ditto ]
Breakspeare [the beer at CPA 2002]
Butts [ ditto ]
autonomy
really-very-very-fast-and-very-very-safe-and-very-very-dynamic
msp (mobile sequential processes)
mobile
kroc
Well - someone did say things had been too quiet ... ;)
Peter.