You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2002/06/12 17:10:51 UTC
Re: [VOTE] Let's get real: let's make Avalon 5 the real stable
Avalon (was Re: [Summary] Avalon 5 ComponentManager interface)
> > 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.
this has to do with presentation and not with stability.
> > 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)
avalon framework 4.0 was released 30 July 2001, after 3 beta versions in
May and June. Before that, it was not stable. After that release, we
have had a few maintainance releases, where the most important changes
were to logging code.
> (2) And Berin will say it's a new version, we don't need to be
> compatible (ie deprecation)
he won't.
> 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)
avalon framework will never ever contain containers.
> - better interfaces, like the Service ones, based on real life needs
> (not only mental masturbations)
new interfaces would break compatibility
> - Examples, examples, examples, examples
nothing to do with bugs
> - Usecases, usecases, usecases, usecases
> - Documentation with images, images, images, images
documentation has nothing to do with stability, or bugs. Only with
learning curve.
> This is not a rant but a proposal.
I'm inclined to disagree.
> I want to see votes on this proposal, because we are playing with the
> life of this project.
-1
- Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
perception of avalon (was: really long subjectline)
Posted by Leo Simons <ma...@leosimons.com>.
> > You write with a "[VOTE]" in the subject, to the development list,
> > having committer status to avalon. I didn't figure out you were writing
> > as a user. Even if I did, I would let it show <innocent blink/>, because
> > others might not have figured it out.
>
> ;-)
>
> Till some time back I was only a user, so sometimes it shows.
> I was behind the barricades feeling like Avalon was a sort of ivory
> tower, and heard the same remark from many guys.
we're ready for a user list I guess =)
nice one, btw..."ivory tower"...but we're of course a bit more like a
beautiful white city where everyone good of heart (and programming
skill) is welcome, a city promoting the universal good, the center of
what will be the most beautiful software package ever (integrating
allmost all of jakarta) governed over by a round table, where stout
knights (committers) sit as equals...
(!)
> Ok, I was messy. The problem comes with older Avalon, between Avalon
> major versions, and having to deal with dev versions.
>
> Avalon is so cool, that many projects just start using dev stuff, and it
> gives bad pubblicity to a family of products that is really stable.
yup.
> I want this stability to remain in the switch to the new version, and
> hope that the 5 version can bring more *percieved* stability, hence the
> reference to docs, examples and reference implementations.
I think what will bring more percieved stability is a stable release of
all the important parts of avalon framework.
Thing is, it is all very usable now:
- there's a stable framework
- a stable logkit
- a stable container (ECM/ECS)
- some stable reusable components for use with ECM/ECS
all of which are supported and do their job. We also have lots of stuff
not marked as stable which is mixed up, in presentation and CVS, with
the rest.
Once we start filling the builds/ directory (Paul is doing a great job
to get this working, btw, with some assistance from the other "release
managers") this'll be easier.
> What I meant:
> "Stability of interfaces and package names has been giving problems to
> Avalon developers between some major Avalon releases.
> I hope that we can change package names and interface names as little as
> possible, concentrating on the conceptual inefficiencies that we
> internally percieve as bugs, like the Component interface and other
> marker interfaces, rather than creating more stuff."
+1. Don't see it as a bug though. Just something that could be improved
a little bit.
> > If you would just have said: "I would like to see avalon have better
> > documentation", you'd get a "me too", and any patches/commits that'd
> > provide such documentation would be very welcome (you'd get a "you
> > rock").
>
> Personally I understand the difficulty, since I have problems in
> documenting Centipede. It's really hard, I know.
yup. And the closer you are to the code, the more difficult.
> I will commit some images, I think that they speak a thousand words.
cool beans! (I'm saving up a "you rock" for the occasion :P)
- Leo
--
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)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
>>Don't have time to reply ATM, but you have been a bit pricky on my term
>>usage.
>>I know what Avalon Framework is, I know that one thing is documentation
>>and code-implementation, I have written a GUI framework on top of it, I
>>know Cocoon since 1.7, and IMHO the way you have replied gives credit to
>>what I wrote.
>>
>>I was writing as a user, you have replied as an *Avalon* programmer ;-)
>>Bad luck, you scared me away; better luck next time ;-P
>
>
> You write with a "[VOTE]" in the subject, to the development list,
> having committer status to avalon. I didn't figure out you were writing
> as a user. Even if I did, I would let it show <innocent blink/>, because
> others might not have figured it out.
;-)
Till some time back I was only a user, so sometimes it shows.
I was behind the barricades feeling like Avalon was a sort of ivory
tower, and heard the same remark from many guys.
I know it's not the case, and I would really like that it shows...
> You stated more or less that avalon 4 is not stable.
>
> This is bad for avalon, for users of avalon, for me, my company.
... and of course, my stupid ranted proposal had the opposite effect, as
you kindly point out. Sorry :-/
> Thus my reply. It is vital to not have anyone think that avalon is not
> quite as stable as it claims to be.
Ok, I was messy. The problem comes with older Avalon, between Avalon
major versions, and having to deal with dev versions.
Avalon is so cool, that many projects just start using dev stuff, and it
gives bad pubblicity to a family of products that is really stable.
I want this stability to remain in the switch to the new version, and
hope that the 5 version can bring more *percieved* stability, hence the
reference to docs, examples and reference implementations.
> I recognize that avalon can use better documentation (I don't think more
> of it would really be very good - there's loads), but as your e-mail had
> a subject possibly indicating that avalon 4 is not "real stable", and
> your e-mail contains statements such as
>
> "stability was never seen in avalon"
> "I would REALLY like to see AF 5 be a big fat bugfix release"
Oops, my cyclical recurring "don't reread the mail bug" :-/
What I meant:
"Stability of interfaces and package names has been giving problems to
Avalon developers between some major Avalon releases.
I hope that we can change package names and interface names as little as
possible, concentrating on the conceptual inefficiencies that we
internally percieve as bugs, like the Component interface and other
marker interfaces, rather than creating more stuff."
> I hope you will forgive me for not mentioning that indeed our
> documentation is not very easy to digest and instead concentrating on
> indicating that these statements are unfounded.
My bad.
> If you would just have said: "I would like to see avalon have better
> documentation", you'd get a "me too", and any patches/commits that'd
> provide such documentation would be very welcome (you'd get a "you
> rock").
Personally I understand the difficulty, since I have problems in
documenting Centipede. It's really hard, I know.
I will commit some images, I think that they speak a thousand words.
> call me pricky if you like =)
;-)
hehehe
You were only correct, I hope I explained myself now.
--
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)
Posted by Leo Simons <le...@apache.org>.
> Don't have time to reply ATM, but you have been a bit pricky on my term
> usage.
> I know what Avalon Framework is, I know that one thing is documentation
> and code-implementation, I have written a GUI framework on top of it, I
> know Cocoon since 1.7, and IMHO the way you have replied gives credit to
> what I wrote.
>
> I was writing as a user, you have replied as an *Avalon* programmer ;-)
> Bad luck, you scared me away; better luck next time ;-P
You write with a "[VOTE]" in the subject, to the development list,
having committer status to avalon. I didn't figure out you were writing
as a user. Even if I did, I would let it show <innocent blink/>, because
others might not have figured it out.
You stated more or less that avalon 4 is not stable.
This is bad for avalon, for users of avalon, for me, my company.
Thus my reply. It is vital to not have anyone think that avalon is not
quite as stable as it claims to be.
I recognize that avalon can use better documentation (I don't think more
of it would really be very good - there's loads), but as your e-mail had
a subject possibly indicating that avalon 4 is not "real stable", and
your e-mail contains statements such as
"stability was never seen in avalon"
"I would REALLY like to see AF 5 be a big fat bugfix release"
I hope you will forgive me for not mentioning that indeed our
documentation is not very easy to digest and instead concentrating on
indicating that these statements are unfounded.
If you would just have said: "I would like to see avalon have better
documentation", you'd get a "me too", and any patches/commits that'd
provide such documentation would be very welcome (you'd get a "you
rock").
call me pricky if you like =)
regards,
- Leo
--
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)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
> -1
Don't have time to reply ATM, but you have been a bit pricky on my term
usage.
I know what Avalon Framework is, I know that one thing is documentation
and code-implementation, I have written a GUI framework on top of it, I
know Cocoon since 1.7, and IMHO the way you have replied gives credit to
what I wrote.
I was writing as a user, you have replied as an *Avalon* programmer ;-)
Bad luck, you scared me away; better luck next time ;-P
--
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>