Stephen, >>> 1) Merlin includes phoenix-client.jar and provides alternate >>> implemetations of the BlockContext interface. >>> >> >> Thats the only real solution at this stage. >> > > If this is the only real solution - would it not make more sense for > this to be included as part of the Phoenix CVS?
Which bit are you agreeing to? 1) Merlin includes phoenix-client.jar as-is for Phoenix compatability. Or are you asserting that 1.1) Alternate implementations of BlockContext need to be in Phoenix CVS? > Given that there is a possibly of Phoenix changing keys (as per your > note below), at least all of the sources impacted by such a change > would be under the scope of the team dealing with the change. This > would at least eliminate the obligation of other container authors to > track and maintain micro-forks of phoenix-client.jar. But it would not eliminate the obligation of other container authors to track changes, with a view to updating their CVS instance of phoenix-client.jar. I don't buy the argument that the GenericBlockContext changes need to be in Phoenix CVS. Other container authors are going to have to conceptually subscribe to something, unless their whole container is in Phoenix CVS and build from the same script. Stephen, using phoenix-client.jar as-is is a good solution. > The alternative is micro-management of phoenix-client.jar variations > by other container project interested in maintaining compatibility > with the Phoenix environment. I'm interested in knowing what Phoneix > committers this about this. Is this is a good thing given the > probable/inevitable de-synchronization of multiple phoenix-client.jar > files? The de-sync of jars covers multiple things for multiple projects. Why is phoenix-client.jar a special case? Nobody (you or Peter) has explained to me yet why phoenix-client.jar as-is cannot be imported into your CVS, in the same way that it is imported into thord-party component writer's CVS depots. >>> ) Change cornerstone comps to use Context as is, and access things via >>> 'Object get(Object)' >>> >> >> This may work for somethings but the key will change in the future. >> This wont work for somethings - especially once interceptors are >> integrated properly. >> > > Presumably the key values that Phoenix publishes in its API will be > maintained in order to guarantee consistency with existing > applications. For example, James has recently dropped direct > references to the Phoenix BlockContext interface in favour of the > reference to the published Phoenix key value. I'm not 100% sure why theu did that.... It seems to have lead a recommendation from the Avalon list, and also be in adnavce of any known problem with Phoenix.... > Should James committers (and other external projects) be concerned > about incompatible key changes in the near/medium-term future? I'm > confident that the Phoenix team will ensure compatibility - which > suggests that perhaps this solution "would work". I think we are anal about backards compatibility in Avalon yes? Remember the discussion over ComponentManager and ServiceManager? > Given that there is work ongoing concerning a common set of attributes > and keys, is it likely that the changes in Phoenix will be > synchronized with other Avalon projects? In particular, could someone > involved in Phoenix comment on the proposed attribute and context key > values published under the excalibur/container package? Phoenix does not use excalibur/conainer, how can it's work be described as definative for Phoenix? Peter has container kit as a dependant package for Phoenix. You know that Stephen. "Could anyone involved with Phoenix....excalibur/container" is an unhelpful comment. > I'm very interested in moving this forward with the objective of > getting in place at a small but concrete set of cross-container solutions. > >>> 3) Create a new interface in A-F called say DirectoryNamedContext. It >>> has the two methods in BlockContext and extends Context. BlockContext >>> extends it. Cornerstone comps drop to DirectoryNamedContext. Merlin is >>> able to trade without reference to Phoenix. Adding an interface in this >>> way, as we all know is a backwards compatible thing. >>> >> >> Fails to add value. >> > > I would agree that this is a zero value proposition if we look from > the internal perspective of the Phoenix project in isolation from the > numerous other container activities related to Avalon. Things become > more interesting when we take a more holistic view of the world, in > particular, the existence of other projects dealing with similar > concerns. Perhaps the added-value is something we can provide to our > users - user's interested in consistency between different containers, > consistency in semantics, and comfort in the knowledge that multiple > projects are working together in the ultimate objective of delivering > the best value proposition possible. I should point out that I don't > think a common interface is terribly high on the agenda when compared > to things like common context key, meta-data attributes, common DTDs > for meta-info. At least the feeback I'm getting is that the > user-community wants to see interoperability and consistency. > > I do you think that someone writing code against a container neutral > interface would feel that they are getting value from cross-project > collaborative initiatives. Stephen dude, that sentence does not parse.. > I do not see how this would fail to add value towards the Avalon > user. Perhaps you could provide your recommendations for the best > approach for users who are considering the development of new > components that they indented to be container neutral? A Phoenix > wrapper hides the problem, but I don't think this is the best approach > given the different features and benefits presented some of the more > recent generation containers? Now mate, I'm getting worse again. I'll reread later and see if it makes any sense! It looks at first glance like sales blurb for Merlin - Paul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
