Please indicate you stance on the following issues, since I am currently completely lost in what we want. These are issues that are close to /my/ heart. Feel free to add to your own to the list.[X] Correct
Components are more than code.
[X] Sometimes
Components should come in "a box", dropped in place and used without even need to look at it.
Depends on the situation.
Simplicity for Component User more important than simplicity for Container Developer.[X] Correct
NOTE: within limits.
Simplicity for Component Author more important than simplicity for Container Developer.[X] Correct
NOTE: Again, within limits
Simplicity for Component User more important than simplicity for Component Author.[X] Huh?
Seriosuly, it should be just as easy to use a component as it is to write it. It shouldn't be that hard. Its a wash.
Without a large Component Repository, COP is pretty meaningless.[X] Incorrect
COP has more value as a way to manage change within an application. Every push to create the large component repository has failed. The latest form is the Web Services approach, and that seems like it would be a better bet. That said, COP is more useful than just services and prepackaged components. Yes you can increase your reuse (you can't ever achieve 100% reuse), but there is value and meaning to COP outside of the already available components.
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.[X] Correct
Avalon is about a domain-neutral server framework.[1][2][X] Correct
NOTE: We should make it as easy as possible for the current domains that it is already used.
Components should be runtime replacable. A true server doesn't need restart.[X] Correct
NOTE: Not as a requirement, but as a feature.
Avalon-compliant Components could be made to work in non-Avalon-compliant containers, effectively running as POJOs, by the Component Author.[X] Huh?
What is a POJO? I don't get it. Of course the reverse is true as well. As long as you have the proper factory to start up the component, any container can run any type of component. It's not hard. Should Avalon tools be restricted to Avalon components? I would say so. But it would be bad if we cannot run components designed for other frameworks just because.
These are values that I carry dearly, without mentioning any approach, design or implementation aspects of our community. As you may understand, they are all formulated in such a way I will answer "Correct" to all of them
Yes, but I can't as they are written. I would answer "Correct" for many as you saw, but at the same time there are some fundamental differences of oppinion.
I would also appreciate that no elaboration is given in the response mail, just to keep it clean. Post those separately.
Sorry. Elaboration is kept small though.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
