Notes taken by RD at the meeting of June 24th


Aimar - Compass
Apostolakis - GEANT4
Duellmann - RD45
Harvey - LHCb, LCB architecture proponent
Innocente - CMS
Mato - LHCb, chief architect
Schaffer - ATLAS
Stickland - CMS reconstruction
Tuura - ATLAS

Subjects : Treat both the above people's ideas, as well as BaBar, and others.
Meetings: 5-6 times before end of September
Record: no detailed minutes, make web page with links to other documentation of interest


David - should err on the side of discussing and try to understand each other, but do not worry about "agreeing" on a common approach, ... although terminology should be ageed upon.

Comments noted during and after Lassi's talk:

Control framework - make sure the right thing runs at the right time
Forward chaining control, as opposed to backward chaining
Primarily is OO design, core of the infrastructure is in C++, but not necessarily influenced by C++.
Designing a tool kit, not a framework - co-operating classes
Vision: toolkits - event storage, visualisation, control

Lassi's terminology :
toolkit - group of foundation classes or "vocabulary" which work together to perform a functionality. Contains most of the abstract
framework - starts to begin to take over the application, one plugs one's things into a framework to do what one wants
component - not necessarily object oriented, is a binary object with a well defined interface

Instant gratification:

Framework separate for the components - framework doesn't know about the data components, except which shared library to load
Notifications are sent when data changes
Object Network is not a framework because a network can execute in any context.


Pere - what happens to detector data?
answer - just another component

Swing - when an event is queued, it is  immediately sent to the listeners. In this model, the events are not sent immediately, only
after dependencies.

Dirk - The paradigm resembles that used by Iris Explorer (IE). Is the IE approach appealing to physicists?
ans - other problems with IE. When people are asked to describe their problem, most people reason in terms of data flow diagram. It may be
that people are not used to "not being able to state the order in  which modules execute".

Pere - what about case statements: similar to LabView, for different types coming out different subnetworks are run - a CASE or SWITCH
ans - build a switch component to decide

Pere - how does a component know when the end of the event comes?
ans - Today, one has to have an input to Event, and do something when the event has changed.

Dirk - Can one have multiple processes on different machines?
ans - Yes, but use corba, or something. But db transactions must be dealt with.

Alberto - Can one object be in C++ and another in Java?
ans - Will introduce a Java facet to communicate from C++ to Java.

Harvey - Strategic design decision: note fundamental difference between this approach and that used by LHCb and BaBar. Atlas decide  for not communicating through the event to avoid global knowledge. David says that CMS have also chosen this approach.

Pere - How does one describe the network?
ans - Now it is the main which instantiates the module objects and makes the connection. There will be an independent textual  description which can build the network.

Suggested topics for future meetings:

Building frameworks/Physical Design - tutorial, fix the terminology, what are the issues, look at Taligent white papers.
Interfaces and integration technologies - (Pere)
Data storage - transient and persistence
Integrating G4 toolkit into framework
Libraries of reusable code - user interfaces, ...
Java - mixing with C++ (Corba IDL), Java libraries
Review workshop contributions
BaBar - David Quarrie's experience

Suggestions for next two meetings:

8 July - tutorial
15 July - David Quarrie on BaBar