avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Context - a future
Date Mon, 25 Nov 2002 14:40:44 GMT


Paul Hammant wrote:

>My intention was for someone other than you or me to lead this...
>  
>

Paul:

I'm not attempting to lead anything - I am attempting to get some 
clarification.  Getting a response from you to this email and the 
questions I have asked would be helpful for to understand what exactly 
the problem is you are tying to address, secondly, if my understanding 
of your objectives are correct or not, and thirdly, establishing if my 
conclusions regarding solutions are consitent with your or not.

I look forward to that clarification.

Chers, Steve.


>-ph
>
> --- Stephen McConnell <mcconnell@apache.org> wrote: > 
>  
>
>>Paul:
>>
>>One thing missing from your message is the problem statement.  I've been 
>>really confussed about a lot of the posts on this subject because it has 
>>been very unclear what peoples objective are.
>>
>>As I see things, we have some fixed and imutable facts
>>
>>  1. Context exists at the framework, and is not about to go away
>>  2. Extending the context interface has ramifications
>>
>>       a) if we are providing a convinience interface only
>>          then this is manageable, via
>>
>>           - a small number of standard context accessors
>>             interface enhancers that are handler by
>>             container implemetations
>>
>>           - maintaining correspondence with get( key ) so
>>             that any component can fallback to the framework
>>             contract if it chooses to
>>
>>           - supplimented by a set of recognized standard
>>             keys specifications
>>
>>       b) if we are supplimenting context with behaviour, then
>>          we are dealing with both a component (client) issue
>>          and a container issue
>>
>>           - this is an issue for a component author if the
>>             author wants to maintain component portability
>>
>>           - this is an concern of a container author if the
>>             author wants to provide adaptability
>>
>>       c) recognizing that there is a gray area between the
>>          two extremes (a) and (b) where standard context entries
>>          can be used to construct more sophisticated context
>>          implemetations (i.e. interface does not do direct
>>          mapping to data but behaviours are exclusively derived
>>          from data accessible grom get( key ) )
>>
>>            - this is resolvable by following standard
>>              patterns on context implementation creation
>>
>> From the above - (a) is easy to do and should not disrupt anyone - (b) 
>>is much more about context management in general under container space 
>>and should be dealt with container implemetations for the time being as 
>>there is a lot more thinking that can go into this area.  Finally, (c) 
>>is easy to do simply by following the existing framework patterns 
>>establish for the creation of DefaultContext.  
>>
>>If I understand your position correctly, I think it falls within the 
>>scope of (a).
>>
>>In particular, if we look at cornerston components and thier depedence 
>>on BlockContext - we see that this depedence is actually limited to 
>>getWorkingDirectory() - or whatever the operation name is.  It would be 
>>better if we provided something like:
>>
>>  /**
>>   * This is a convinience accessor to the standard
>>   * avalon context entry "avalon:work".
>>   */
>>   interface WorkingDirectoryProvider
>>   {
>>       File getWorkingDirectory();
>>   }
>>
>>The Phoenix BlockContext could be revised to the following:
>>
>>   interface BlockContext extends WorkingDirectoryProvider
>>   {
>>       // plus Phoeinix specific
>>   }    
>>
>>This would shift cornerstone components from being depedent on Phoneix 
>>to being dependent on framework based interface.
>>
>>Does this help? Am I correctly interpriting the problem?
>>
>>Cheers, Steve.
>>
>>  
>>
>>Paul Hammant wrote:
>>
>>    
>>
>>>Can someone who is _not_ advocating any of the competing propositions for Context
please lead
>>>      
>>>
>>this
>>    
>>
>>>task:
>>>
>>>We need a 'roll-up' on this rapidly sprawling thread.  Many people (incl me) are
being lost in
>>>      
>>>
>>the
>>    
>>
>>>extensive detail.
>>>
>>>1) What are the competing solutions .. hashmap style get(), cast to Context derived
interfaces
>>>      
>>>
>>etc
>>    
>>
>>>...
>>>
>>>2) What is the timescale we are trying aim for?  Can it go into Phoenix and Merlin
or is it a
>>>revolution, thus only for uber-container?
>>>
>>>The idea is that we get one summary of the choices.  It may be that me, Stephen,
Leo(s) post
>>>comment and the rollup is modified.  Best to leave the start of this to unaligned
person
>>>      
>>>
>>though.
>>    
>>
>>>Nicola: Can you arbitrate if too many step forward?
>>>PeterD: Can you post an opinion on Context?
>>>
>>>Regards,
>>>
>>>- Paul
>>>
>>>
>>>__________________________________________________
>>>Do You Yahoo!?
>>>Everything you'll ever need on one web page
>>>      
>>>
>>>from News and Sport to Email and Music Charts
>>    
>>
>>>http://uk.my.yahoo.com
>>>
>>>--
>>>To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
>>>For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
>>>
>>>
>>>
>>> 
>>>
>>>      
>>>
>>-- 
>>
>>Stephen J. McConnell
>>
>>OSM SARL
>>digital products for a global economy
>>mailto:mcconnell@osm.net
>>http://www.osm.net
>>
>>
>>
>>
>>--
>>To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
>>For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
>> 
>>    
>>
>
>__________________________________________________
>Do You Yahoo!?
>Everything you'll ever need on one web page
>from News and Sport to Email and Music Charts
>http://uk.my.yahoo.com
>
>--
>To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
>
>
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




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


Mime
View raw message