Dear Bob:

Frank Belz (TRW), John Kinney (Stanford), Andrew Landisman (TRW) and I
discussed Rapide 
http://pavg.stanford.edu/rapide
and Demeter technology interaction during Wednesday afternoon (March 18) 
in LA. Your intuition was right that here is a fruitful technology 
integration possibility.

We identified four ways of possible integration:

1. Using Rapide event analysis tool to analyze events produced by distributed,
   adaptive programs.

   This integration is straight-forward because of the modular nature of
   Rapide and their work on Java events. We translate adaptive programs into 
   Java programs and the Rapide team already has a 
   Java preprocessor to instrument Java programs so that they 
   produce time-stamped events during the execution of the distributed 
   Java application. The generated event posets are then analyzed by
   Rapide for example, if an error occurred, and we would like to know
   where it came from.

2. Using the Demeter strategy graph notation and algorithms in Rapide.

   Frank Belz was pointing out that when he analyzes posets, he would like
   to have a strategy graph like notation to express anchored 
   pattern searches of posets. The strategy graph notation is simpler
   than the current Rapide notation but seems to cover many commonly
   occurring queries, according to Frank. The current Rapide notation is
   not structure-shy. Since the Rapide pattern matching technology 
   is general, the algorithms are slow for big posets.

   The Demeter algorithms for strategy graphs are fast in their limited domain
   and would help to analyze large posets quickly.

   The Demeter algorithms for strategy graphs are available in source
   form (Java) on the net and we would be happy to help to incorporate
   them into Rapide by polishing the API of those algorithms and by
   maintaining them. Those algorithms are at the core of Demeter/Java.

   The Rapide team describes the need for fast pattern matchers and
   better pattern matching notations in:
   http://pavg.stanford.edu/rapide/rapide-pubs.html

3. Using strategies to define the events of interest.

   A third integration possiblity is to use
   strategies and visitors to specify the events which are of interest.
   This would allow flexible instrumentation of Java programs and it would
   reduce the size of the generated posets.

4. Frank Belz was pointing out that it would be nice if the Rapide tool set
   would be easier to modify by TRW. I mentioned several success stories
   where conventional programs have been implemented using
   Demeter/Java to simplify maintenance of the programs.
   I think that in Demeter/Java form, Rapide would be easier to 
   develop further. As a test, the Rapide poset analysis software could
   be implemented using Demeter/Java.


Frank Belz was instrumental in coming up with those ideas.
I look for your guidance regarding what should be done next.

Best regards,
-- Karl