Subject: My notes from the Rain meeting
From: Keunwoo Lee (klee@cs.washington.edu)
Date: Thu Jan 31 2002 - 12:29:00 PST
I think it would be productive to start a discussion, both in email and in
meetings, about what we took away from the Rain meeting. Here are my
mental notes; maybe this will start a thread. I've already mentioned the
basics of these to some of you.
~k
+ Communicating independent processes, with guaranteed delivery, where
services are names that can be passed around the system, is very close to
the pi calculus!
+ One important difference: they do not appear to have the notion
of "broadcast on a channel"; every process effectively has a unique
"in" channel that it listens on. So, in fact, the rain system can
be viewed as a restricted system of processes in the pi calculus.
+ The reliability and in-order guarantees match closely with the
synchronous version of the pi calculus, not the asynchronous
variant used by e.g. Pierce et al. for Pict.
+ The XML-based message passing leads me to believe that some of the
machinery developed for XDuce could be used in a domain-specific
programming language. Programmers really want to pattern-match over XML
trees and then execute code. The "natural" way that I imagine programming
in this paradigm is something like the following:
component foo =
<msg name="bar"> * </msgname> => ...
<othermsg> <tag id="x" /> * </othermsg> => ...
This looks a lot like the case statement in XDuce (except they use square
brackets instead of matched tags). I expect, though, that the Rain
programmers want
+ ordinary OO code for most things that are not components,
+ inheritance among components
neither of which are supported by XDuce, which is ML-like, of course.
XDuce also provides some strong guarantees that will probably have to be
sacrificed due to versioning of messages etc.
+ XML is not just an artifact of wanting SOAP/.NET interoperability.
Fundamentally, the idea of passing semistructured data enables the
evolution of messages. Old versions of a piece of software can extract
only those pieces that they understand, and punt on the rest.
Semistructured-ness can also be used to "mixin" pieces of data, e.g. for
audit trails. It's possible that these properties could be added in using
an object model not tied to semistructured data, but it's not obvious to
me how to do it nicely.
+ What are the properties that one might want to prove/infer over programs
written in Rain? There's a lot, but here's my current list of things that
might be interesting:
+ "Will all messages will be understood by their recipients?"
This is the standard interface-matching problem, except there's
probably versioning issues, plus the semistructured data issue.
+ "What is the minimal environment of services that this component
needs in order to operate?"
I have a PDA in my pocket, and I walk into a room and boot it up.
I want to know which components are going to work, so the software
should figure this out and present it to me. Presumably there's
some sort of service discovery process; you would like to discover
only the services that you need, rather than overloading the room
by asking it to send every available service. Even better would
be incremental levels of discovery, supporting increasing amounts
of functionality.
+ "Given that this group of components share some secrets, can I
verify that some things are never transmitted unencrypted?"
It seems like this is an application for the security calculus
work by Abadi et al.
+ When a component wants to wait for multiple related messages to arrive,
perhaps something in the vein of the C# concurrency stuff presented by
Cardelli et al. at FOOL would be nice. Match over a set of messages, and
then execute the body.
+ Easy optimization: execute some parts of the body eagerly, before
all the pieces arrive, by using data dependence.
+ Elaboration: produce specialized versions of eager execution to
handle different orders of arrival.
+ In one of the code fragments Stebbi showed us, he used a "continuation"
object to wait for the reply to a message and execute some code. This is
an obvious opportunity for language support... forking N continuations to
wait for N replies should be easy from the programmer's point of view.
Of course, once you want to receive a message, you get back into the XML
pattern matching issues. You would like to be able to wait for an
ordinary XML message, i.e. you do not want to force the remote component
to send you some magic "continuation cookie", because the remote component
should not have to know that the result is being used as part of a
continuation. So, continuations may have to cooperate with top-level
matches to determine who handles a message.
_______________________________________________
Cecil mailing list
Cecil@cs.washington.edu
http://majordomo.cs.washington.edu/mailman/listinfo/cecil
This archive was generated by hypermail 2b25 : Thu Jan 31 2002 - 12:30:11 PST