The following refers to the draft text of the COST proposal.
Minimum of 5 countries - we have 7 for now (Denmark, France, Germany, Ireland, Italy, Portugal, U. K.)
Deadline: September 30
Body of the proposal should have 10000 characters maximum (excluding title and abstract)
According to http://w3.cost.eu/index.php?id=833#1686 and to http://www.cost.esf.org/participate/guidelines, the proposal should have exactly the following top-level headings, with the content detailed below:
1. BACKGROUND, PROBLEMS
2. BENEFITS
3. OBJECTIVES, DELIVERABLES AND EXPECTED SCIENTIFIC IMPACT
4. SCIENTIFIC PROGRAMME AND INNOVATION
5. ORGANISATION
BACKGROUND should start with a very clear statement of the problems we want to solve and why they are important. This statement must start from practical problems relevant to society. Technical challenges in computer science, which are what we really want to work on, arise because of the inadequacy of current computing technology in solving society's problems.
BENEFITS should be about how research in this area will benefit society
OBJECTIVES should be both:
(a) the objectives of the research programme (which we are working on without the resources of COST), which the COST will help to achieve; and
(b) the objectives of the COST itself, such as organizing workshops, funding PhD mobility, producing surveys or reports, etc.
SCIENTIFIC PROGRAMME has to be what we are doing already through our nationally-funded projects. (Note that I don't think this nationally-funded research has to take the form of grants from national funding agencies; it could be the research we do using the resources that we have in our institutions. It just means that we are doing it without resources from COST). The working groups should then follow from a sub-division of the scientific problems; then we can find the detailed objectives, deliverable and work programme for each section.
WORKING GROUPS. the ones currently listed are one possible structure. However, it seems to me that security is of a different character than the others. Security needs to be considered in relation to foundations, languages and applications. So another possibility is to have a security working group, and three others of similar character. For example: evolution, progress&fairness, verification. This would give us a structure similar to a suggestion by Sophia Drossopoulou (SEE BELOW). Then, for example, the security working group would look at foundational calculi that include security, make sure that language designs for security are working from appropriate foundations, coordinate between language designs and tool implementations, and consider case studies for security.
Part of the added value of the COST would then be to ensure a flow of ideas from foundations, to languages and tools, to applications.
Simon: I think we have to say that there is a large, widespread, general and urgent problem involving the increased use of large-scale distributed and communicating systems as part of the technological infrastructure of modern society. There are serious questions about how to engineer reliable and secure systems. In our discussion in Lisbon, I think there were some examples from sharing medical records, or more generally distributing personal information among government agencies and across national boundaries. Anyway, to build reliable distributed systems we need theories and tools for understanding interfaces and how to construct systems from components. Ultimately, everything depends on powerful programming languages and tools, with rigorous foundations, that will make it easy to engineer the kind of system that society is increasingly dependent on. We argue that behavioural types are a key technology, because: types are the formal language in which to describe interfaces; behavioural types can describe protocols; and we also have to consider dynamic behaviour in relation to interfaces (e.g. interfaces that change with time). Behavioural types allow us to analyze dynamic properties such as deadlock, which can't be analyzed by a static notion of interface. Also security can be integrated in a natural way.
Then we should think about how we want to apply behavioural type theory in order to solve all the problems of large-scale distributed systems. This leads to several themes:
I had a look at some existing COST proposals (from a very quick Google). Even though the call says that COST doesn't fund research (i.e. it is just travel and networking, not funding for researchers), it seems clear that we have to have a research programme with some goals and activities. Other COST actions seem to have working groups on various sub-topics. Perhaps the idea is that the research itself is being funded at a national level, but the COST action puts another layer on top and enables us to coordinate and focus our activities.
Probably we need working groups on particular topics, and perhaps these working groups should produce reports or surveys of research in each topic.
SOPHIA says: yes, my experience with COST is that we need to have some working-groups working on particular questions, and then the working groups have to report progress on that question. How about something like the following as working groups:
KOHEI says: I agree with these observations, by Simon and Sophia. I think the current text is doing what is needed: to link smoothly the general backgrunds Simon wrote above to those technical points Sophia pointed out, as well as other notions.
I still wish to write down a bit my take on this linkage. Generally, I believe we can safely say that methods based on communicating processes are the only way we can give a good, usable basis for many kinds of software-related activities from now on, including programming languages, analysis, runtime management, development in general, education, and others. In particular we can list what Simon wrote (software technologies for large-scale distributed infrastructure, involving technologies from webs and clouds), as well as programming for many core chips. Generally, we want a core principle and methodology with which all kinds of software can be programmed, built, and analysed, across different application areas: each application will demand a different expertise, but we want a common basis. And this common mode of constructing computation will centre on communications.
That is, I believe, why we need a way to analyse, control, verify, manage and in effect understand software constructed from communicating processes: and the current knowledge on computing does not own any well-established way to do so, not to speak of those which are well-shared. And any widely and durably usable technologies in this regard can be based on precise analysis of software behaviours (semantics), and their syntactic manifestations, types and logics. We can also point to the fact that using communications among concurrent modules enable a very complex, dynamic organisation of software behaviours, much more than existing ones.
I think the text done so far gives a good link from what we can envisage in general in computing reality, to the technical expertise we share, with clear discussions on the background and state-of-the-art in related fields, both in science and technologies. I will try to add some points which may be strengthened.