[prev in list] [next in list] [prev in thread] [next in thread] 

List:       avalon-dev
Subject:    Re: ROLE & Lifecycles in C#
From:       Stephen McConnell <mcconnell () apache ! org>
Date:       2003-07-30 14:58:11
[Download RAW message or body]



Geer, Christopher S wrote:

> 
> 
> > -----Original Message-----
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > Sent: Wednesday, July 30, 2003 9:14 AM
> > To: Avalon Developers List
> > Subject: Re: ROLE & Lifecycles in C#
> > 
> > Geer, Christopher S wrote:
> > 
> > 
> > > > If there is already a IDisposable.Dispose(), then why not use it?
> > > > 
> > > > 
> > > What
> > > 
> > > 
> > > 
> > > > context is it used with?  I see no sense in reinventing the wheel.
> > > > 
> > > > 
> > > I agree we should use the provided interface if we can.
> > > 
> > > 
> > > 
> > > 
> > > > Short list is:
> > > > 
> > > > Configurable
> > > > LookupEnabled
> > > > Initializable
> > > > Disposable
> > > > 
> > > > 
> > > I'm assuming that you mean to role start() and stop() into
> > > 
> > > 
> Initializable
> 
> 
> > > or something? Also, what about Suspendable, Reconfiguration and the
> > > other Re's? Personally I beleive that those are very important
> > > interfaces to support. While you could just role those into the list
> > > above that would almost require everyone support them, which would
> > > 
> > > 
> mean
> 
> 
> > > if someone didn't want them they would just have empty methods,
> > > 
> > > 
> giving
> 
> 
> > > someone a false belief that the compoenent actually supported them.
> > > 
> > > 
> > All the Re's should be removed until we decide what to do with them.
> > Noone has come up with a good idea for any of the Re's or how to
> > 
> > 
> support
> 
> 
> > them.  They are legacy interfaces that in hindsight would have been
> > 
> > 
> better
> 
> 
> > to nix back when we made the Avalon 4.0 baseline.
> > 
> > 
> 
> Getting rid of these for now doesn't really bother me too much.
> 
> 
> 
> > In the future, when we have a requirement for something along these
> > 
> > 
> lines
> 
> 
> > we can discuss how to do it, what the contracts should be, and then
> > 
> > 
> expand
> 
> 
> > the framework.
> > 
> > As to Startable [start() and stop()], it seems redundant when we have
> > Initializable and Disposable.  Again, Suspendable is one of those
> > 
> > 
> things
> 
> 
> > that loses any kind of usefulness if there is no reason to temporarily
> > suspend a component (reconfiguration, etc.).
> > 
> > 
> 
> I disagree. I think Startable is an absolutely necessary interface.
> 

I agree.

> There are perfectly valid cases where components may not need to be
> "initialized" but do need to be started and stopped. Also, stop() and
> dispose() have two different functions also, in my opinion. For example
> (and this might not be the best example but...) if you were building a
> web server, you might want to stop the web server from taking requests
> and then collect metrics from the server (while its not changing) before
> disposing of it.
> 

The start stop pair make total sence when you component is a server 
style component.  Initialization is the point where the component 
validates itself relative to everything supplied to it - and start 
signals to the component to commence the process of handling doing 
whatever it does - normally handling requests or whatever.

> 
> While you could wrap the start() method into the Initializable interface
> if we reuse the .NET IDisposable interface we won't be able to wrap the
> stop() method into it.
> 
> 

What's the problem with keeping the notions seperate?


<snip>

> I think there needs to be a way to modify a components configuration without \
> disposing of it and loosing its state information. 
Agree.

Cheers, Steve.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]