From: SMTP%"jbk@FNAL.GOV" 23-FEB-1998 14:20:01.47 To: QZLI CC: Subj: Re: Callbacks in the frameworks & how we got where we are Date: Mon, 23 Feb 1998 14:19:52 -0600 From: James_Kowalkowski Subject: Re: Callbacks in the frameworks & how we got where we are Sender: jbk@FNAL.GOV To: "Gordon Watts (Brown University)" Cc: Serban Protopopescu , Wyatt Merritt , Dhiman Chakraborty , GREENLEE@FNAL.GOV, QZLI@fnald0.fnal.gov, Marc Paterno , Brent May Message-id: <34F1D9E8.952@fnal.gov> Organization: Computing Division MIME-version: 1.0 X-Mailer: Mozilla 2.02 (X11; I; SunOS 5.5.1 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <01ITUNHRLOYI0024O1@FNAL.FNAL.GOV> Gordon Watts (Brown University) wrote: > In the last framework meeting on Weds Jim talked about callbacks and > lakos' dislike of them. I was sick home on Thursday so I pulled out my Lakos > book and read up on callbacks (perhaps that was why I was sick?). > > Indeed, Lakos does not like them and claims that callbacks are a sign of a > poorly designed system. He also does single out our hook objects as a method > of doing a callback. There are many good examples of where callbacks are useful and do not mean the system is poorly designed. > > The example he uses to demonstrate the evil of callbacks is a database. > The database can read in info from several sources, so the database is > passed several parser objects and then the database calls the parser objects > (is this the way the RCP object parser stuff is setup?). His complaint is > that the database really doesn't need to depend upon the parser, rather the > parser should depend upon the database. So, in Lakos' ideal design the > parser should be hoisted above the database, instead of put inside it. This > is the sort of thing he rails against when he talks about confusing program > flow. > There are, of course, many other ways in which callbacks are used, the Lakos database example is just one simple demonstration. > The framework, I think, is a little different. The callback routine isn't > providing a service to some lower level component burried in the framework. > Rather, the callback is the service; it is the upper level component. Yes, the framework is different, and I also don't believe Lakos could put every example of callback design in his book. When it comes to callback program design, I don't quite agree with Lakos harsh statement about them. I think what he says in that chapter is very important, I would probably change it to "The excessive use of callback MIGHT indicate a poorly designed system." The bad design part would depend on the problem at hand. I brought this up as an initial reaction of mine - not necessarily that the design was poor, just that I wanted to understand further the rationale behind the design so as to feel confident that it is the correct choice. I made the statement about callbacks because I didn't want everyone to stop thinking about this part of the problem yet. The current proposed framework addresses registering the callbacks - but not actually invoking them in a clean way. The rules for invoking callback or hook lists are encoded directly in the framework main procedure. This means that the main framework procedure has knowledge of every possible hook list, and the place in which the hook list is processed is fixed. Adding a hook might not effect the user package, and this is of course very important, but is will cause a disturbance in the framework, which I feel is also an important piece that must remain as stable as possible. What I initially felt uncomfortable with is the notion that (1) every form of user or package level processing is done via hook and (2) every hook is completely unique in the system. I guess I'm hoping that there is some relationship between groups of hook, such as: run-control-hooks, job-control-hooks, i/o-hooks, processing-hooks, report-hooks, notice-hooks (this is of course me just thinking out loud). I've seem several very successful callback based system out there. Many of them are GUI frameworks and network client/server application frameworks. All of them were used to handle asynchronous-type processing in a framework driven event loop. > > The other possible arrangement for the framework is something that Marc > and Brent wanted a long time ago: no framework......... I wouldn't think about this, you decided to go the way you did for a reason, I just am trying to think of a good way to organize and utilize the callback lists in the guts of the framework. > > The first attempt to do this was to use a common base class. This is the > obvious solution -- a common base class, each method is a certian hook > (begin run, end run, etc.). The difficulty happens when you sit down to > decide which callbacks to write. A first culling on the Run 1 list got us, I > think, 8 different hooks. The Run 1 list, however, was 30 some-odd hooks. > Some of them no longer needed. So, clearly, there has to be room to expand. As you point out, this does not seems to be a good approach. However, some functionality could make sense in the base class, such as getParameters() and setParameters() (methods that change the packages parameters while it's running). Also maybe a method called getStatusReport() which can be called at anytime to get a simple report defined by the package. Jim