avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject RE: The Roadmap to Beta (or: diving into the fray...)
Date Sun, 22 Apr 2001 13:39:53 GMT
At 02:12  22/4/01 +0200, Leo Simons wrote:
>> >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.
>Ah. We currently have a user pool that is almost not growing.
>Little new users will probably mean little new active ones
>as well.
>Many of the people in that pool work for companies that would
>allow them to work on Avalon in company time as soon as that
>company would start using Avalon - which does not happen
>because there is nothing solid enough for them to use. See?

perhaps but there is little we can do till we reach critical mass. Besides
Avalon and it's ilk is inherently unsexy and fairly demanding - so even if
it increases usage by many times it will only see a small increase in
active developers ;( Have a look at other generic frameworks in OSS land -
they all have similar fates. 

>> >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.
>which happens all the time...and often works as well (I'll
>mention the word microsoft again).

So we should lure people to Avalon by lieing to them? Not my style really.
I would prefer to be an obscure but technically brilliant project rather
than a large sucky project ;)

>> 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.
>That's still pretty vague (more vague than the current docs).
>We've got inversion of control, the COP approach, separation
>of concerns (multi-dimensional).
>Those are patterns.

I wouldn't call them patterns as such - they are more abstract than that -
but then everythings a pattern ;)

>I see the framework as a representation of those patterns
>in code (interfaces with contracts defined in javadoc, that
>We have yet to define _explicit_ contracts for many parts of
>the framework. We currently provide default implementations
>of some parts of the framework (DefaultContext), and not for
>other parts.

Which other parts don't we do.

>This leads to some unclarity of what is the framework, and what

Easy if it has to do with any of the following it is definetly framework
* lifecycle relationship (ie activity, logging, context, CM, config)
* container-component relationship (ie camelot)
* kernel-app-component relationships (ie atlantis)

Certain other "patterns" have also been declared as part of framework
(basically define generic good practices for building component based
systems). Candidates include;
* chained exception classes
* component pipelines (except this is still untested and thus in excalibur)
* thread markers (ie singlethreaded/whatever)
* possibly the command based pattern you/Berin described would also fit here

In neuroscience I would call this "form" functions. This contrasts with
"content" functions such as 

* pooling 
* cli parsing
* db pooling
* thread pooling
etc. (ie include all the components in here)

>> 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).
>I'd solve the interdependency problem with an ant file which
>might even do a unit test to be completely sure, and then put
>indepent components in different dirs.
>I don't see the coupling between CVS and release.

well you a rare individual indeed ;)

>> >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.*".
>that is, imo, not a proper separation of concerns.

why? I still don't understand why you would say this. Users need to access
both implementations and interfaces - just like in swing. Do you think
swing is badly designed? 

Just because it also includes a DefaultTableRenderer when you may want to
write your own does not devalue it's structure. It is one of the few
successful frameworks for java - I am not sure why you would want to go
against a proven model?

>And, if we also want to allow others to do create
>their own implementations of specifications (which
>we do, I believe, at least for several parts),
>this is messy as they'll have to include the
>default implementation as well.

Which parts are we missing default impls for that we should have? 

>> >  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).
>even more complicated!

Right - but it's the way that is being used. Hence why I didn't want
anything in the org.apache.avalon.* namespace. I wanted Avalon as a
covername much like jakarta is cover project for a bunch of smaller projects.

>> >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 ! ;)
>nah. I ment there is the Java Language Specification
>(document/diagrams), the JDK (implementation) and the javadoc
>tool (extension). We don't separate spec from impl.

So if we update the docs does that mean we are separated ? ;)

>> thankfully we have just moved away from that model - it was unanimous
>> decision so you should check archives for reasoning ;)
>did so. My answer would be "ant" to every problem mentioned =)

Right - but by your logic we should include all jakarta projects in one CVS
right? (or maybe all java apache projects - or perhaps the whole jdk ;]).

>> >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
>... ;)
>That's the to-do for cornerstone then =)

true - but thats gotta wait till I am happy with phoenix first.

>dependency would be
>package				CVS		dependencies
>org.apache.log.*			log		none
>org.apache.avalon.*		avalon	logkit

>org.apache.excalibur.*		cornerstone	logkit, avalon

bad to put in cornerstone as most users of excalibur do not need
corenrstones other parts.

>org.apache.cornerstone.*	cornerstone	logkit,avalon,excalibur

>org.apache.phoenix.*		phoenix	logkit,avalon,excalibur,
>							cornerstone

Phoenix does not depend on cornerstone. Think of phoenix as the servlet
spec (ie org.apache.phoenix.*) + a servlet implementation (ie the rest of
phoenix). Cornerstone depends on the spec part - phoenix couldn't care less
if cornerstone existed or not ;).

>and Peter would be right in wanting to create the excalibur cvs.
>Considering I'm -1 for multiple CVSes, but all for following a
>chosen pattern, that makes me +1 for not 1 but two new CVS roots
>(the additional one being ***demos). Not that it matters after
>a veto...

My long term plan was to wait and see how commons worked out. It hasn't
decisevly failed or succedded yet so I would like to wait til that is
definete. If it doesn't succed I wanted to create a new CVS like it but
more open. It would effectively host all the components in excalibur + any
other components regardless of dependencies. (ie demo apps from
cornerstone, my cadestre and ottolith servers, any other products that
needed a place to grow etc). 

Once cjan is done (someone else is working on it - yay !!!!) we should be
able to do this effectively even if commons fails.


| "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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

View raw message