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

> From: Paul Hammant [mailto:[email protected]]
> 
> 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.

All the phases are concepts.  If you have a concept, you
need to describe it.


> > 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.

The whole concept?


> 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.

What about merging Contextualizable, Configurable, and Parameterizable?

i.e.

interface ConfigurationManager
{
    Logger getLogger(); // can be its own interface...
    Context getContext();
    Configuration getConfiguration();
    Properties getProperties(); // replace the proprietary parameters.
}

interface ServiceManager
{
    Object lookup( String role ) throws ServiceException;
    boolean hasService( String role );
}


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

I think we are leaning towards a fragmentation of concerns as opposed
to proper separation.

Consider Parameterizable and Configurable--they have the same function.
Even Contextualizable provides *global* information with any type of
Object (like File, URL, etc.).  Arguably they can be moved into the
same space.


> 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?

That would be fine.  Updating a configuration is very important, esp.
if you have hierarchical containers.  Not everyone needs it, but we
need a standard mechanism so that the container can support it easily.
Using a separate object that is shared between the container and the
component works *much* better than having the component try to directly
save it.


> 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>

You better duck!  ;P

Castable sessions and castable contexts are bad.  If we have a standard
extension mechanism, just pass in your application specific context.


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

I think in another thread you are not following your own advice ;P

My RTs and stuff are just that, random thoughts.  I just want to get
it out there so that when we are ready to pick back up we have some
conversation pieces.  I am not calling any votes--I haven't even
put up a proposal yet.