At 08:21 8/04/01 +0200, Leo Simons wrote:
>> > += org.apache.phoenix.atlantis becomes an implementation
>> > and extension of the Kernel, Embeddor and JMX Manager
>> > interfaces.
>>
>> Perhaps org.apache.phoenix.engine.atlantis.* ???
>
>Not wat I was thinking. The current engine.* is an implementation
>of atlantis.* ... while the implementation is complete (or nearly
>so), the interfaces aren't =)
Okay - I think I get you. The only issue is that the kernel stuff has yet
to be widely tested in multiple environments. Until such a thing happens I
think the way is arranged now is fine.
>> > += org.apache.avalon.demos, the current demos from
>> > cornerstone.
>>
>> -1 What do demos have to do with kernel? - especially as they are meant to
>> be demoing the reusable components in the next section.
>
>Nothing. I think Phoenix should be more than the kernel - it should
>be the RI of everything, including the kernel engine.*/atlantis.*/
>whatever.
>It also needs some examples on how to use the kernel.
Okay - maybe we can address this next version but I am not sure it is a
good idea still. Phoenix atm is an Application Server implementation - it
uses framework implementation but isn't one itself. I wanted to introduce a
separate tree for framework implementation but as we want to go stable real
soon now we don't have time.
>> >- I feel a RI also needs a few demos to show how a framework
>> >could be used. This is, again, in line with the model followed
>> >by javasoft (the JMX RI provide some sample MBeans, for example).
>>
>> Agreed. Volunteering? ;)
>
>Hey, I did one already didn't I? Currently, I'm trying to clean
>up the kernel, add JMX to Avalon, and pass all my exams...I'm not
>up to it =)
;)
>> > - likewise, it will be easier to develop a new
>> > implementation as parts of phoenix are easily re-used.
>>
>> Agreed - we have to get one version working 95% before we start
>> cleaning it
>> up IMHO ;)
>
>Hmm. I strongly believe in cleaning up at every stage of development
>wherever possible, as long as it doesn't _reduce_ that percentage.
true - but cleaning things up takes time - and a fair bit of it to do it
good. So I want to have something that is good enough to work with in
meantime.
>I hope I've now clarified that's not what I ment. When you abandon the
>notion "phoenix = kernel" you'll arrive at what I ment and we'll
>probably agree.
I am still not sure - atm I like that Phoenix is an Application Server
implementation and nothing more.
>> I am just taking a slower approach
>
>Are you? I'm trying to define goals that are far in the feature somewhat
>more concrete/explicit than you have. But how far in the future or how
>the timetable should be is not part of my thinking here.
okay. I have a huge list of things that need doing and I am just slowly
going through it - Berin and Fede probably already know but I have very
specific requirements/use-case that I am working towards (DVE/distributed
VR simulator/3d-Game server). If I tried to get everything at once it would
be -1'ed ;) hence I am just gradually molding it ;)
>It's just that since this type of software is quite new, it takes time
>and energy to define those goals and end result in a concrete manner.
>Right now, I'm trying to improve/contribute to the process that leads
>to the definitions of goals and design.
excellent.
>More on sub-projects
>====================
>Generally, no two projects should depend on one another
>(while cornerstone can depend on the framework spec, it
>cannot depend on the impl as the impl depends on
>cornerstone).
unfortunately thats not really viable - unless we go through and create
factories for everything. In some cases blocks require knowledge of
implementation because they need to instantiate and manage
context/CM/configuration objects. (ie see James block in James poject).
>
>Ideal setup:
>
>1 - Avalon specification 'working group'
>2 - Avalon components 'working group' which creates usable
> chunks of code for use in implementations and applications
> using Avalon, probably according to demands from 3.
>3 - Avalon reference implementation (phoenix) 'working
> group' which creates impls of versions of the
> spec from 1 and components from 2.
>
> 3.1 - responsible for the bulk of the RI
> 3.2 - responsible for the atlantis part of the RI
> 3.x - perhaps more sub-groups for parts of the RI,
> like the Logger stuff.
>4 - Avalon documentation 'working group' in which all other
> groups also participate.
>5 - Avalon deliverables/support 'working group' which creates
> distributions and other deliverables and helps people set
> those up, and probably manage the website.
>
>1 depends only on java in general
>2 depends on 3
>3 depends on 1 and 2
>4 has no real dependencies
>5 depends on 1 through 4.
>
>Branding would be the concern for 5. There's no problem with
>both an "Avalon" and a "Phoenix" (sub-)brand, me thinks.
>Perhaps number 2 deserves a nice mythological sub-brand as
>well...
perhaps but thats waaaaay in future - I don't think we should even be
thinking about it for another 6 months ;)
>so instead of the dull "cornerstone" or "component" we
>take _the_ most famous 'tool' from the mr. Arthur legend -
>"Excalibur". Thoughts?
perhaps but (2) is different from cornerstone which specifically host
kernel components and interfaces rather general avalon components.
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]
