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]
