Of course, as many have noticed, this is a very low-precision way of explaining your position, but I hope it will average out in the end...
A more verbose answer follows below my quick answers. > From: Niclas Hedhman [mailto:[EMAIL PROTECTED] > > Components are more than code. > [X] Correct > [ ] Incorrect > > > Components should come in "a box", dropped in place and used > without even need > to look at it. > [X] Correct > [ ] Incorrect > > > Simplicity for Component User more important than simplicity > for Container > Developer. > [X] Correct > [ ] Incorrect > > > Simplicity for Component Author more important than > simplicity for Container > Developer. > [X] Correct > [ ] Incorrect > > > Simplicity for Component User more important than simplicity > for Component > Author. > [X] Correct > [ ] Incorrect > > > Without a large Component Repository, COP is pretty > meaningless. [ ] Correct [X] Incorrect > > > COP is not the same as Java classes defined over an API. I.e. > just because you > can instantiate it, doesn't mean it is a Component. > [ ] Correct > [X] Incorrect > > > Avalon is about a domain-neutral server framework.[1][2] > [X] Correct > [ ] Incorrect > > > Components should be runtime replacable. A true server > doesn't need restart. [X] Correct [ ] Incorrect > > > Avalon-compliant Components could be made to work in > non-Avalon-compliant > containers, effectively running as POJOs, by the Component > Author. [X] Correct [ ] Incorrect VERBOSE SECTION --------------- > Components are more than code. > [X] Correct > [ ] Incorrect Can be more than code, but they don't *have* to be. > Components should come in "a box", dropped in place and used > without even need to look at it. > [X] Correct > [ ] Incorrect Ideally, yes. But we should not limit the box design by *requiring* a certain component packaging. You make me think of .sar or .war files, which are not always the right way to deploy things. However, if you *want* to deploy your components like .war or .sar files, the framework should not make it impossible. > Simplicity for Component User more important than simplicity > for Container Developer. > [X] Correct > [ ] Incorrect > > > Simplicity for Component Author more important than > simplicity for Container Developer. > [X] Correct > [ ] Incorrect > > > Simplicity for Component User more important than simplicity > for Component Author. > [X] Correct > [ ] Incorrect No further comment needed. The above is obvious. > Without a large Component Repository, COP is pretty > meaningless. [ ] Correct [X] Incorrect COP gives you an architectural framework that is very useful even if you have to write all your components yourself. > COP is not the same as Java classes defined over an API. I.e. > just because you > can instantiate it, doesn't mean it is a Component. > [ ] Correct > [X] Incorrect That depends on the component framework. For Avalon, the answer is "Correct" but for COP the answer is "Incorrect". > Avalon is about a domain-neutral server framework.[1][2] > [X] Correct > [ ] Incorrect > > > Components should be runtime replacable. A true server > doesn't need restart. [X] Correct [ ] Incorrect Ideally yes. A component framework should not by design make runtime-replacement an impossibility. But it should not require that components are coded for it. > Avalon-compliant Components could be made to work in > non-Avalon-compliant > containers, effectively running as POJOs, by the Component > Author. [X] Correct [ ] Incorrect In effect, an Avalon component running in a container is a POJO. /LS --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
