> >I'd argue that Avalon indeed _is_ all of those. What we could
> >do is remove all but the framework from Avalon and put it in
> >separate projects (reusable components go to commons, phoenix
(...)
> >this would probably be disastrous to Avalon.
(...)
> I like to think of them as sub-projects of avalon which hopefully wont
> affect the brand - what do you think?
I feel that there should be a cleaner separation between the
different sub-projects than there is now (we're moving in the
right direction =), but that they should all be 'subbed' to
the framework specification.
> Not stable enough yet
=) I'm talking completely theoretical here; I think it is best
to have your long-term goals well-defined so you can work towards
them a little bit in everything you do. I don't mean all of the
stuff I'm mentioning should be done this year...but we all need
to be perfectly clear on where we want to be.
> > += 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 =)
> > += 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.
> >Notes:
> >------
> >- I feel the framework should also define how components/blocks
> >are handled, and thus define what our current phoenix should
> >look like.
>
> Not sure what you mean here - I though it did ? ;)
By contract, but not by interface. This can be made more
explicit.
> >- Moving the implementation of the specification to phoenix will
> >strengthen phoenix's branding (tomcat is the RI of specs
> >defined by javasoft, phoenix is the RI of specs defined by
> >apache Avalon).
>
> will do that in the future but it is not yet stable enough to do
> this IMHO ;)
Totally agree :)
> >- 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 =)
>
> >Summary:
> >--------
> > I think it is the best move in both a logical and a
> > marketing sense, to make Avalon a specification of a
> > framework, and Phoenix the reference implementation
> > of that framework.
>
> Depends on what you mean. In 90% of the places I use the Avalon
> "framework"
> it does not have anything to do with a kernel and thus I don't see how
> making phoenix the RI is useful.
Phoenix ?= kernel
Currently, yes, but it could be more. Phoenix would be
the RI implementing every aspect of Avalon, including the
kernel as an important part.
Of course, you could use (Phoenix - avalon.atlantis
implementation) in many places (your 90%).
> > - 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.
> >Finally:
> >--------
> >I realise that what I've lined out here is a big move from the
> >current setup. I decided to look at the issue of organisation
> >with a clear mind, forgetting what I knew of the current setup.
> >This led to this proposal. Please try to look at it purely from
> >a design POV first, without bothering with the things that might
> >be broken. Hopefully, you'll agree with me this is indeed the
> >smartest thing to do.
>
> I think that except for merging notion of kernel and non-kernel stuff I
> agree except as indicated above ;)
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 don't want to merge the kernel in with the other stuff. I want the
implementation of the "other stuff" to also fall under the phoenix
naming umbrella (and thus under its package). This means a redefinition
of what Phoenix is, not of how the (abstract) relation between Kernel
and non-kernel should be.
> 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.
I'm guessing all of us actually have almost precisely the same ideas of
what we want to happen to Avalon; all of the different goals from
different responsibilities (project manager, sys admin, branding exec,
geek-who-likes-cutting-edge-stuff, etc) lead to the same thing in the
end here.
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.
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).
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...
so instead of the dull "cornerstone" or "component" we
take _the_ most famous 'tool' from the mr. Arthur legend -
"Excalibur". Thoughts?
cheers!
LSD
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("[EMAIL PROTECTED]");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
