At 09:39 21/4/01 +0200, Leo Simons wrote:
>I do recognise that the debate is getting heated and that
>viewpoints are no longer defended with logical arguments but
>instead with emotional ones.
This isn't heated - you need tougher skin if you think that ;) Simple
really - this is opensource - you have an itch then scratch it - but don't
expect others to do the work for you.
>where it is not:
>----------------
>Also, presenting a beta means having to support it which
>means cycles that cannot be devoted to development. While
>a release means a bigger use base
If you have a read of the article I sent just a bit back you will realize
hopefully the use base means nada - the key is activity of users. In many
ways an increase in user base can be a negative as it forces stagnation ...
err stabilisation ;)
BTW beta == we provide quarentees that products based on it will be
forwards for the major version.
>2) THE FRAMEWORK goes beta
>(i.e. everything in avalon.*, excalibur.*, framework.*,
>etc)
excalibur is NOT part of the framework - it has nothing to do with the
framework - it just happens to be some components that USE the framework
and we happen to use the components aswell.
>3) PART-OF-FRAMEWORK goes beta
>This is the current proposal; it is supported (AFAIK),
>in concept, by everyone. The stable, tested parts of
>the framework code goes beta; the rest does not.
keyword: *framework* ;)
>2) What is the problem?
>On the one hand there is the risk of putting too much
>into the beta so we have to update it 3 times a week
>with major changes.
that is not a beta no matter what label we place on it - that is just an
alpha that someone decided to relabel.
>On the other hand there is the problem that arise when
>we put too little in the beta: apps that wish to use it
>get very little functionality.
The apps that use the *framework* get very little functionality already -
it is not intended to provide functionality but to be *framework*/patterns
etc. When you think of "framework" think of Component model.
>3) How do we solve that?
>Lots of discussion, of course. We still don't have a
>real starting point for this...I'd say the primary user
>of Avalon to target with this release (it is the only
>public, open source, jakarta-hosted, closely-tied
>project, and probably the most widely used one as well)
>is Cocoon.
>So, logic would dictate (as mr. Vulcan would put it)
>that we include all materials in the beta that are
>vital to Cocoon.
Instead of worrying about cocoon in general lets be concerned more with
cocoons users in particular. They are the important ones. We can always get
the cocoon developers to update the DB pool impl because they found a
threading bug or something similar but it is completely unreasonable for us
to expect their users to go through and update things (like method
signatures or packages etc).
>4) Which materials are vital to Cocoon?
>We don't have an exhaustive, detailed, accurate list.
>Can someone from Cocoon (probably Berin) provide one
>as the basis for further discussion?
Required to be 100% stable for beta:
* framework (as defined above)
* interfaces in excalibur.pool
* interfaces in excalibur.dbpool
They also use: (but we don't need them to be 100% stable)
* impls in excalibur.pool
* impls in excalibur.component
* impls in excalibur.dbpool
* impls in excalibur.cli
>AND THEN WHAT?
>--------------
>
>Having avalonapi-4.0b.jar is only a first step. Clearly,
>this is a more-or-less temporary solution until the entire
>avalon-XXX CVS material has a final release (more likely
>several different releases for different use-cases).
The reason for separate CVSes was to decouple the release schedules so we
should be able to release any part at any time. It was also to decrease
that chances of interdependencies exists (still hasn't been completely
successful - see clutil.jar in testlet CVS).
>My last e-mail had suggestions about that. It snowed in a
>bit in all the discussion. Basically, I want to define the
>relationship between different namespaces / avalon
>components more explicitly.
>
>I proposed a model of
> 1) specification (avalon.*)
> 2) reference implementation (phoenix.*)
Yep and I said whats wrong with swings model. The specification and
implementation are both in "javax.swing.*". Considering it is the most
similar example of a framework (The only other framework that I am aware of
in javaworld that has been *standardized*).
> 3) extensions (of both spec and RI)
> 4) pluggable, common components
kernel components (aka Blocks): cornerstone
non-kernel components: excalibur
> 5) programs on top of Avalon
phoenix is on top of avalon's framework
james is on top of phoenix
cocoon is on top of avalons framework
> 6) external APIs
???
>2) why can't we use the framework model, like is done with
>Swing?
>
>me:
>
>I can't really see how the 'new' Avalon would look if we
>use the Swing model rigourously.
Avalons framework would look similar enough to what it looks like now ;)
(ie identical).
>Also, I'm not quite sure exactly what a framework model really is.
ahhh ... like swing ;)
> Avalon has a much more complex structure than that.
> Automated/rapid server application programming is a lot more
> complex (probably not easier!) than GUI programming.
Avalon is not just server related - it is a component model (aka
framework), some components (most of which aren't server specific), it is
an application kernel (that is *slightly* server specific) and it is a set
of kernel services (that is server specific).
> It requires
> a different approach (first came J2EE, then came .Net. Now,
> there is Avalon. <-- how's that for a slogan =).
;)
>I dunno. It may be appicable. I think the spec with RI and
>extensions is better (more examples: the Java Language Specification
>with JDK as spec and RI, and javadoc as an extension;
thats the model we have now ! ;)
>Now how do we implement that?
>-----------------------------
>
>If I'd start from scratch, I would just have a single
>avalon cvs with the following...
thankfully we have just moved away from that model - it was unanimous
decision so you should check archives for reasoning ;)
>This is, essentially, what has been done for Tomcat 4.x
>(they've got Catalina and Jasper in the same CVS, but in
>different trees).
right - ask around a few people if they think this is a good thing ;) (Even
better yet - ask the developers themselves if in retrospect they would have
chosen this).
>Pete's list included again:
> * finalize *activity* related methods (init/start/resume/etc)
> * move processor methods to excalibur
done.
> * write a python/perl/other script to convert (i am currently using elisp
> which is not useful to everyone else)
will do now ;)
> * move camelot/atlantis to phoenix CVS
done.
> * remove compat hierarchy (done, right?)
done.
> * migrate code in avalon.util to better resting place
> (either as components in phoenix or into the void)
almost done (still thinking about remainder of stuff).
>- stabilise LogKit (it already is, isn't it? =), and create
> a release (does it even need a beta?);
doesn't really need a beta-izing (unless we want to clean up it's bad
design decisions now ;]). However I would prefer we didn't try to release
it publicly as IMHO it would be bad for Apache to have two separate logging
toolkits out.
>cornerstone
>- I still don't get what it is; it's a bit messy
> and javadocs are out-of-date. I thus won't try
> to make a list here...
awww - this is one of the few bits I am happy about ;) docs lack though ... ;)
>more phoenix
>- another round of refactoring and testing;
>- phoenix beta;
>- create a release which we can label as 'probably
> suitable for everyday use' with avalonapi,
> logkit and phoenix in it. I personally would
> really like to see this before the end of
> July...I guess a lot of that depens on how much
> time I put in myself.
yup ;)
>more avalon
>- merge excalibur with avalon again;
-1 for all the reasons already indicated before - but you knew I was going
to do that right?
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
