Hi Bob:

Ok, I will take the lead on 1 and I will find out whether the Rapide
team makes any assumptions about the Java programs which their
instrumentation software processes. Hopefully they can take any
Java program, including the ones generated by Demeter/Java.
We will need a grammar for their log files and the semantics of them.

I will talk to Frank about 3. 3. is very interesting if the
distributed applications are written in an aspect-oriented style
using strategies.

Thank you for bringing us in this direction.

-- Karl
=================================================

>From rladdaga@darpa.mil Fri Mar 20 12:29:39 1998
>To: "'Karl Lieberherr'" <lieber@ccs.neu.edu>
>Cc: Frank.Belz@trw.com, hgill <hgill@darpa.mil>, salasin@arpa.mil,
>        "'David Luckham'" <dcl@arachne.stanford.edu>
>Subject: RE: Demeter/Rapide
>Date: Fri, 20 Mar 1998 12:27:33 -0500
>
>Karl:
>
>The first integration notion was the basis of my intuition.  I think that
>you should investigate how to start using the Rapide event analysis tools.  
>
>I'm pleased about the other three integration possibilities, but clearly you
>can't take the lead with numbers two and four.  If Frank or David (or
>someone in their groups)  would like to take the lead on either or both of
>2,4,  then I would be delighted to have you support their effort in any way
>possible.
>
>You might be able to take the lead on number three.  It would be interesting
>to know what is required to interface a third party event defining tool into
>the Rapide toolset.  Perhaps you and Frank could together agree to take the
>lead on that one, with help from David's group. 
>
>Comments?
>
>Bob
>
>	----------
>	From: 	Karl Lieberherr[SMTP:lieber@ccs.neu.edu]
>	Sent: 	Friday, March 20, 1998 10:01 AM
>	To: 	rladdaga
>	Cc: 	Frank.Belz@trw.com; hgill; salasin@arpa.mil
>	Subject: 	Demeter/Rapide
>
>	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
>
>