Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 59585 invoked from network); 25 Nov 2002 14:04:57 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 25 Nov 2002 14:04:57 -0000 Received: (qmail 12333 invoked by uid 97); 25 Nov 2002 14:05:57 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 12317 invoked by uid 97); 25 Nov 2002 14:05:56 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 12305 invoked by uid 98); 25 Nov 2002 14:05:55 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <3DE22D47.1030800@apache.org> Date: Mon, 25 Nov 2002 15:01:43 +0100 From: Stephen McConnell User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Avalon Developers List Subject: Re: Context - a future References: <20021125130237.61590.qmail@web13409.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: >For additional commands, e-mail: > > > > > -- Stephen J. McConnell OSM SARL digital products for a global economy mailto:mcconnell@osm.net http://www.osm.net -- To unsubscribe, e-mail: For additional commands, e-mail: