===  Gordon Watts's comments ===
   on "manager-driven black box framework proposal"
                (Nov. 20, 1997)



  I was unable to attend the meeting yesterday (I'm in
Providence right now), so I thought I would read the
web pages at http://d0server1.fnal.gov/users/paterno
/public_html/framework/framework.html.

  First, on your point of using mixed languages. I do not
agree, and I must say, I'm surprised that Harrison also
does not agree; or was your test beam experience worse
than I thought? The point behind python was to make
the framework more flexable, not less. The end user, the
package writer, would never have to deal with that section
of code. 

  I also think we are fools to go off and try to
write the dll linking code ourselves. At the very least
we should steal the code from python or some similar
utility. Finally, having done a little research into how
link libraries work, I think we need to do a little more.
Questions like how do DLL globals link up with globals
in the main program? How many entry points can a DLL have?
How do you do object method calls across DLLs? Can it be
done?  Worse, I don't think a DLL (NT) and a .so (UNIX)
act the same.  Because of the time that will be spent
developing the dynamic link interface, I think it should
be put off to the end.  Actually, I've just finished
reading a talk by Laura Paterno about ACE, a framework
that we are using in the online group. It includes platform
independent dynamic linking.

  Your second point about developing a batch framework.
Yes, D0RECO is needed now, but if you don't design in
the stuff for the interactive framework, you'll end up
having to repeat all of your work. Worse, the packages
that everyone writes for D0RECO will have no formal
user interface. This means that during design and writing
of the package people will write their own. Once D0
specifies the analysis interface, no one will go back
and rewrite what they've done to fit it (well, very few
people will). I do think you need to approach this as
a single problem. The batch environment that D0RECO exists
in is a nice clean one. Unfortunately, the environment
that most people use is not: analysis (interactive & batch
at the same time). We must design the interfaces to package
parameters, to the packages themselves, and to the bits
of the framework with this in mind.

  In the last paragraph you have a quick comparison between
the two proposals, where you talk about pulling apart the
concept of a registry and a factory. If I understand what
you are talking about, then I agree, that is a difference.
We have formalized the concept. The formalization forces the
user to add one line of code to their .cpp file in exchange
for not having to put together the framework by hand. This is,
in my opinion, a big simplification.

  I'm glad to see that the proposal made by Herb, Dhiman,
and myself is converging towards the ideal you list in your
web page. It sounds to me that the two are very close,
though it is hard to tell without seeing some class
diagrams.

	Cheers,
		Gordon.