In response to Peter:
> no idea - I would -1 the Executable name in favour of something else
> (Animatable or Active???). Still can't think of a good name for
> Interruptable thou ;)
Component == Passive entity
Composer/Composable == Active entity
So that's not a real option.
Processable?
Process?
Threadable?
Program?
Why was it again that Interruptable was a bad name? Perhaps...
...scratches head...can't think of anything else either ;/
> -1 on adding commands at this stage
I agree. Untested code should not go in a beta. But do we move there in
the future or not?
In response to Berin:
> I see what you are saying, however, the mechanism that developers
> use may not necessarily be the Interruptable interface. The
> contract simply says that the component must remain in a consistent
> state during reconfiguration. This could simply be done with a
> Lock object that is released when reconfiguration is finished.
> I think in this respect we should not tie the implementation of
> the Interruptable interface to the Re*able interfaces. Especially
> since they can be passive objects (not Executable or Interruptable).
Oh. Uhm. Yes. Totally correct =)
> > 5 - it is currently stated that start(), run() and stop() may be
> > called multiple times. I have a problem with that - some Components
> > may not support this behaviour (I don't think they should), while
> > some containers may require it. The replacement would be the use
> > of Commands.
>
> Think of a J2EE server. It should be possible for the administrator
> to stop and restart the Servlet Container as many times as they need.
> The important contracts to maintain are that start() cannot be called
> before initialize(), and stop() cannot be called after dispose(), and
> that Interruptable methods cannot be called when the component is
> stopped.
Yep. But a Container now needs to distinguish between a Component that
only allows start() and stop() to be run once (which imo should be
possible),
and a Component that allows it to happen multiple times.
How do we do that?
> Personally, I think that the Command infrastructure should be considered
> as a mutually exclusive relationship to Executable/Interruptable.
Me too, however...
> However, since this is nearly impossible to enforce, I will agree to
> your lifecycle proposal for their placement.
cool beans.
> Also, I believe that the Runnable interface usually tied to Executable
> should be handled by the Component, not necessarily the framework. It
> is assumed that between start() and stop(), we are executing the code
> for run().
Also agree on that one; it is unclear to me how far we are in
changing this (checking)...almost done. I'll update the lifecycle
doc =)
...
I think Commands should be used as untested code currently in
excalibur.command, that may move to a more prominent place if
it is used.
cheers!
LSD
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("[EMAIL PROTECTED]");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
