On the need for suspend/resume ------------------------------ Our usage of start/stop versus start/stop is quite different. We use 'start' to invoke startup of an ORB and stop to shutdown the orb. Our implementation uses suspend/resume as points where ORB traffic can be suspended, but the active ORB is still valid. This condition enables the establishment of a quasi-stable environment under which some administrative actions can be performed in the knowledge that the number of in-memory components is stable.
On the question of binding together init/dispose ------------------------------------------------ During the discussion and messages exchanged about the lifecycle operations I looked into the pairing question concerning init/dispose. While in principal this looked like a match, our code provided a different story. In our code there is a high usage of the Dispose interface - basically we use this as the general cleanup operation to dispose of an in-memory slots etc. A sub-set of this code uses a much wider set of lifecycle operations together with an extension of Disposable called Vulnerable - which is an interface which deals with disposal of a persistent object identity (with operations 'expendable' and 'terminate'). Even in the case of Vulnerable interface we found that there was not a need to pair this with the init operation because the majority of our objects are constructed through factories that return fully initialized objects. Cheers, Steve. > -----Original Message----- > From: Peter Donald [mailto:[EMAIL PROTECTED] > Sent: Saturday, 21 April, 2001 05:37 > To: [email protected] > Subject: [Framework] Dualities in Activity methods > > > Hi, > > Theres a few concerns I have relating to the activity related lifecycle > methods and changes proposed recently. It was identified that there is no > real need to separate suspend/resume features. They were effectivly a dual > that were codependent. It was then further identified that > start/stop was a > dual and *should* be codependent. Further more suspend/resume requires > start/stop. > > Taking this one step further we would see that Initialize/Dispose are a > dual aswell and by the same token should be kept together. There could be > also an arguement that start/stop *should* extend initialize/dispose. > > thus we have > > interface ID > { > initialize(); > dispose(); > } > > interface SS extends ID > { > start(); > stop(); > } > > interface SR extends SS > { > suspend(); > resume(); > } > > This is what is the "proper" way of doing things. I had a look through my > own code, avalons code and other codebases (ie turbine) and found > that most > of the code did not follow this pattern. So naturally I feel a little > uncomfortable at changing our pattern at the eleventh hour before we got > beta when it has yet to be tested. > > I also don't really like the proposed name. I already use Executable in > another interface name as do a few other projects (most likely > ant aswell). > The Blahable name is also an accepted pattern for interfaces with a single > method blah() - I don't think we should change that. Possible alternatives > I could think of were > > Constructed - the Initializable/Disposable dual > Active, Animated - the Startable/Stoppable dual > ReBuilder??? - the suspend/resume dual > > Then I began thinking ... do we even need suspend/resume? What does > suspend/resume give us that start/stop doesn't give us? > > start/stop could be called multiple times in lifecycle of component, only > while stopped could you recontextualize/recompose/reconfigure. So what do > you think - do we need suspend/resume? > > Fede also expressed some reservations about the package name > "org.apache.avalon.lifecycle" so I propose the name > "org.apache.avalon.activity". > > Thoughts? > > > > > > Cheers, > > Pete > > *-----------------------------------------------------* > | "Faced with the choice between changing one's mind, | > | and proving that there is no need to do so - almost | > | everyone gets busy on the proof." | > | - John Kenneth Galbraith | > *-----------------------------------------------------* > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
