Leo Simons wrote:
On Sun, 2002-11-24 at 16:39, Stephen McConnell wrote:If I remember correctly things just got too complicated and after a while the team had to backtrack and unwind changes. I don't recall exactly what the issue were that raised the complexity. It would interesting to know more about this.
<snip/>
What we have in the framework today are nice set of abstractions. They don't define any paricular service - they simply provide the defintion of many aspects of the contract from a container to the compoent.agreed.
This thread is talking about the laying in of specific services into the framework contract.
I think that is dangerouse.
<snip/>
Secondly, (b) - the whole notion of mixing in services into context simply defeats the purpose of the existing framework service management contract (Serviceable/Composable, etc).note: these things are never black and white. In the phoenix world
(geared at managing, for example, a servlet engine), it really makes
sense to provide context.getHomeDirectory(). In the "tweety" world
(geared at managing, for example, HelloWorldComponents), it doesn't.
<snip/>
Pete goes on to say:
You could mix concerns but that makes for a more complex configuration setup as now you have to be aware of the differences between container provided and peer provided services and how that effects interaction with them. It also makes the internals of the container much harder to maintain. We actually started to do that about 2 years ago but after a few months decided to back it out.I understand why Pete is this. He has attempted to deal with this from the context (no pun intended) of a monalithic container where functionity appears from within the container implemetation, not as a result of peer services.
nah. What we were experimenting with then (IIRC) was making a lot of the stuff that is now in the phoenix components package into "facilities" (ie phoenix-provided services, sort-of phoenix kernel plugins) that one would load from a "facilities/" directory, ie quite microkernel-like. You might have "facilities/commandlineprocessor.far" or "facilities/sarfiledeployer.far". I can't remember exactly why it didn't work out (could be cuz I left for Oz or somethin' and missed the outcome ;)
Choice of words wasn't good.
I think we've learned a lot since then and I still believe this would
work (reference: merlin). But it sure wasn't because phoenix was
monolithic. There was a conscious decision to go for the level of
'monolithic' phoenix has now. I think the phoenix kernel is more compact
because the decisions made then :D
ContextDescriptor & componentinfo.dtd (or whatever that stuff is called)
in the meta/info packages is the way forward I think.
<snip/>
If you answer is NONE - we can move forward with resolution of the real problems that are inhibiting the proper use of the framework.
eh? Framework is improperly used? Where's what problem?
What I mean is that we are experiencing inconsitent and conflicting use of the framework that will not disappear until:
(a) divergence in semantics are resolved
* through resolution of issues at the framework level
* through development of compatiple solutions to enable easy
client application migration
[think lookup semantics divergence between ECM and Phoenix cultures]
(b) we figure out and resolve the problem that Pheonix has
* to minimise impact on portibility
(e.g. a standard getWorkingDirectory() opp on
interface along the lines Leo's suggesting which
abstract out Phoneix in terms of depoedencies)
* enhance the Phenix platform to provide better support
container provider service provision to components
(c) which will lead to strengthening of the framework contracts
I.e. I don't see the problem as Context - I do think that the symptoms of other problems are being expressed though context variants - and getting to those problems involves issue at the framework level (which are expressed as inconsistency in contract usage).
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
