Re: [RT:A5] What are the _real_ concern areas?

Berin, 

> There are two major differences.  There is a new overall phase
> (Transition), 

Transition. Neat.  However, I'd like to see a another interface in that 
phase (not withstanding lifecyle extension), to think it was worth a 
name on its own.

> which means the component can claim or release any
> runtime resources that it will need for processing.  This brings clarity
> to the difference between Initializable/Disposable and Startable.
> The second difference is that the Re* interfaces are now handled by
> a ServiceListener class.  It will receive ServiceEvents if the container
> has new configuration information available for it, or a different
> set of services available.
>
> It is also important to note that Initializable/Disposable can only be
> called once (each), and Startable can be called any number of times.
> Startable.start() brings the component from Transition to Active Use,
> and Startable.stop() brings the component from Active Use to Transition.
> Once the component has been disposed, can never be brought back to
> life.

That is stated already I think (website)

> interface ServiceManager
> {
>      Configuration getConfiguration();
>      void writeConfiguration(Configuration config)
>              throws ServiceUnavailableException;
>
>      Object lookup( String urn ); // context and service combined
>
>      Session getSession();
> }
>
> interface Session
> {
>      Object get( Object key );
>      void put( Object key, Object value );
> }
>
> Any thoughts or inputs?

I don't like, sorry.

When I look at a class and peer at its 'implements' declaration I learn 
a lot.  If I see Startable I guess it probably has daemon functionality 
or some sort.  When I see Contextualizable I reckon it has some 
configuration somewhere.  Declared lifecycle methods tell me a lot.

Just because we can 'simplify' interfaces to a smaller set, does not 
mean we should.  

Having said that you raise the issue of updating configuration again. 
 Leo Sutic did a great definition of our stance on Context, that he 
might want to step up to a similar role for this?

Also, Session as you have it here has clashing method namespace with 
Map.  Not good.  I'd prefer Sessionable passing in a Session (which has 
getters and setters).  <duck>I'd also like to allow bespoke containers 
have castable Session interface.</duck>

Lasty, Can we wind down for seasonal festivities please?  No votes for 
the next 10 days?

Regards,

- Paul