[VOTE] Let's get real: let's make Avalon 5 the real stable Avalon (was Re: [Summary] Avalon 5 ComponentManager interface)

[Nicola Ken Barozzi <ni...@apache.org>]

Leo Sutic wrote:
> 
>>From: Leo Simons [mailto:leosimons@apache.org] 
>>
>>
>>>Leo Sutic wrote:
>>>
>>>>Carsten,
>>>>
>>>>you are right - everything gets a little bit more complicated.
>>>>
>>>
>>>Yes, and this is the thing that worries me - I know a lot of people 
>>>saying "Avalon is too complicated" and this makes it even a 
>>
>>little bit 
>>
>>>more complicated,
>>
>>hmm. Is it more complicated?
> 
> 
> As Vadim said in a comparison of Cocoon and Struts: Cocoon developers
> come from the "pattern hell" school of thought. (That was a point
> against Cocoon, if anyone missed it.)

And against Avalon.
It's so easy, that it's too hard (not a joke).

> Worth thinking about, as I have seen some people here accusing
> Cocoon of not following patterns cleanly enough.
> 
> As a matter of fact, I think we scare the shit out of most people
> with the complexity of the framework already. Patterns within 
> patterns... It is not whether there are patterns or not - it is 
> the fact that you have patterns of patterns, and you must somehow
> grasp them all.

Correct.
After a week of teaching Avalon, I showed 2 implementation classes.
They said "is it this? easy!".

Users are better off seeing it's easy and that it works for them rather 
that being told how it was concieved.

> So I completely understand Carsten. We will lose users. I see
> before me someone saying "F*** it. (1) They are obviously not committed
> to API stability, (2) just about when we've finally learned to use
> the framework (given how complex it is that may be a while), the next 
> change will come along, (3) the cost of maintenance and keeping up 
> with that will kill us. Let's roll our own framework."

(1) Berin can say anything ;-P but stability was never seen in Avalon (bad)
(2) And Berin will say it's a new version, we don't need to be 
compatible (ie deprecation)
(3) Seen that, been there, heard it. It's true.


> If it is more complicated or not does not matter - what matters is
> what it is *percieved* as.
> 
> For all its faults, A4 is *easy* to *use*. (Although I confess I never
> ever understood the RoleManager.)

You know what?
I would REALLY like to see AF 5 be a big fat bugfix release with regards 
to A4.

That is:
- real-life examples, with ready to use containers (Merlin, Phoenix, etc)
- better interfaces, like the Service ones, based on real life needs 
(not only mental masturbations)
- Examples, examples, examples, examples
- Usecases, usecases, usecases, usecases
- Documentation with images, images, images, images

It will have to *look* new, but will be what AF4 wshould have been all 
way long.

If we change interfaces too much again we will loose our users.
We will. Believe me. Many told me.

This is not a rant but a proposal.
I want to see votes on this proposal, because we are playing with the 
life of this project.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [VOTE] Let's get real: let's make Avalon 5 the real stable Avalon (was Re: [Summary] Avalon 5 ComponentManager interface)

[Nicola Ken Barozzi <ni...@apache.org>]

Leo Sutic wrote:
> 
> I agree with your vision, I think, but I'd like you to
> specify exactly what that vision means in terms of Avalon code:
> What interfaces do we change, and how? What else needs to change,
> and how?
> 
> That said, I think we do need a bit more user-orientation and less
> obsessiveness about what consitutes "good architecture" and "proper
> SoC, IoC" and other fancy terms... Sometimes I think we're getting
> a bit overboard and justify our architecture with statements regarding 
> what we consider "good architecture/philosophy etc." and not in terms of
> how good and useful for our users. If this is the "less wanking" point
> on Nicola's list, then I am
> 
> +1
> 
> just for that reason. I think we risk building all these air castles
> that no one will ever find useful irrespective of how mathematically
> or academically correct they may be unless we start checking ourselves.

I will send you my mails to you personally next time, you make a 
wonderful job in explaining :-D

Sometimes I wonder how I get to write so convoluted stuff :-/


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [VOTE] Let's get real: let's make Avalon 5 the real stable Avalon (was Re: [Summary] Avalon 5 ComponentManager interface)

[Leo Sutic <le...@inspireinfrastructure.com>]

> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org] 
> 
> You know what?
> I would REALLY like to see AF 5 be a big fat bugfix release 
> with regards 
> to A4.
> 
> That is:
> - real-life examples, with ready to use containers (Merlin, 
> Phoenix, etc)
> - better interfaces, like the Service ones, based on real life needs 
> (not only mental masturbations)
> - Examples, examples, examples, examples
> - Usecases, usecases, usecases, usecases
> - Documentation with images, images, images, images
> 
> It will have to *look* new, but will be what AF4 wshould have 
> been all way long.
> 
> If we change interfaces too much again we will loose our 
> users. We will. Believe me. Many told me.
> 
> This is not a rant but a proposal.
> I want to see votes on this proposal, because we are playing with the 
> life of this project.

OK - can you rewrite your points as a proposal. That is, what
exactly is it you are proposing? Especially "better interfaces"
is a bit vague in combination with "If we change interfaces too 
much again we will loose our users."

I agree with your vision, I think, but I'd like you to
specify exactly what that vision means in terms of Avalon code:
What interfaces do we change, and how? What else needs to change,
and how?

That said, I think we do need a bit more user-orientation and less
obsessiveness about what consitutes "good architecture" and "proper
SoC, IoC" and other fancy terms... Sometimes I think we're getting
a bit overboard and justify our architecture with statements regarding 
what we consider "good architecture/philosophy etc." and not in terms of
how good and useful for our users. If this is the "less wanking" point
on Nicola's list, then I am

+1

just for that reason. I think we risk building all these air castles
that no one will ever find useful irrespective of how mathematically
or academically correct they may be unless we start checking ourselves.

/LS


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>