On Thu, 2004-03-11 at 18:51, Hamilton Verissimo de Oliveira (Engenharia - SPO) wrote: > -----Mensagem original----- > De: Peter Courcoux [mailto:[EMAIL PROTECTED] > > > It appears to me that the A4 framework implies a series of individual > > contracts Configuration, Contextualisation, Servicable etc. AND an order > > of execution. > > Yup, although its sometimes implict.
But perhaps it shouldn't be... > > I think I disagree with LS thoughs in sense of we are delivering an Avalon > container, so - damn its Avalon - the container should know the steps of > execution that he must obey, and guarantee its order. It must pass on the > future tck. I agree that there should be an Avalon reference implementation and a tck. I agree that the container should know the steps of execution that it must implement AND their order. This is a set of contracts and an EXPLICIT statement of the order of execution. > > Other strategies like Pico or Spring could be plugged into one of these > execution steps - the avalon ones - not requiring a different handler, just > different aspects/concerns implementations. > This is just an implementation detail. > The current situation of Aspects proposal is more like a generic component > container where Avalon is just one of the possibilities. I think being a bit > more restrictive wouldn't kill us :-) but I might be wrong! > But I think that you can have the best of both. Avalon 4 contracts that specify particular concerns and the Avalon 4 specified order of execution. But merely by changing the execution chain specification and adding or removing the contracts you can move to Avalon 5, 6, 7 ... without changing the container. And if you are writing components for a j2me app you can lose the bits you don't need and still be Avalon compliant. Your component will still run in the reference implementation container. > About turning some phase on/off - at first this was my intention in castle, > but in a second though I don't think its good. The user turning off a > configuration phase for instance can guarantee that it won't affect his > components, but can't say anything about 3th parties components being used. > So, if the kernel don't have a concern/aspect specified for a particular > phase it should use a default one. > An Avalon 5 compliant container will have to provide the Avalon 5 facilities and the Avalon 5 specification chain of execution. Defaults are fine. But why not allow the removal of unused bits by those developers who don't need them? > just my 2 cents as usual. > and my £0.02p ;-) > Peter > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
