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 <ma...@leosimons.com> on 2001/04/03 21:44:57 UTC
Avalon logo...
...I've tried to incorporate all your suggestions and
made some new logo. These are very simple and print
well in b/w.
comments?
Leo
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("mail@leosimons.com");
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>
Re: back to branding
Posted by Peter Donald <do...@apache.org>.
At 05:35 6/04/01 +0200, Stephen McConnell wrote:
>
>G'day Pete:
>
>> The problem is associated with our branding - what do we
>> want to be branded as? Because Avalon used to be much bigger
>> (It incorporated both Cornerstone and Phoenix) many people
>> associate it with Phoenix. Others associate it
>> plainy with framework part ... others the components etc.
>
>Today the Avalon "brand" covers three things (and don't hesitate
>to correct or suggest other views), and its in the definition of
>these three things that I think the "branding" question get
>confusing:
>
> 1 "Avalon - the framework stuff"
> 2. "Phoenix - the engine stuff"
> 3 "Cornerstone - the blocks stuff"
I would actually separate it out like
1. General purpose utility code
2. Framework code
3. Components
4. Application kernel
5. Services for Application kernel
org.apache.avalon, the package hierarchy currently contains (1)-(3).
>Today Avalon (the brand) represents 1, 2 and 3. In Pete's message
>he's talking about Avalon in terms of point 1, not in terms of 1..3.
>I think that maybe we do have a "brand management" problem (wow,
>actually got in the 'm' word on an open-source list :-)).
;)
>There are two exit mechanisms here:
>
> 1. rename "Avalon the framework stuff" to something
> new and exciting then update everything so that the
> common message is that...
>
> Avalon (the brand) is:
>
> "XXXXXX - the framework stuff"
> "Phoenix - the engine stuff"
> "Cornerstone - the block stuff"
This is is my ultimate goal - part of my agenda ;) I see Avalon as a
spawning ground of related frameworks/technologies etc. As we move closer
and closer to global stabilisation of what is covered by Avalon I would
like the namespace org.apache.avalon.* to be removed.
In the end Avalon would be a cover project with many sub-projects
associated with it in bite-sized chunks ;)
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Avalon logo...
Posted by Leo Simons <ma...@leosimons.com>.
I'm done =)
(well, mostly).
I'm committing the logos as I type this to
jakarta-avalon/src/logos (didn't know where
to put them so put them here; feel free to
modify).
I went out of my way a little bit and did
the logos for phoenix as well, calling it the
RI as proposed in my other e-mail. If y'all
disagree with this, well, we should come up
with another slogan =)
regards,
LSD, who has just finished a week of exams
and is now definately in a party mood
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("mail@leosimons.com");
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Avalon logo...
Posted by Leo Simons <ma...@leosimons.com>.
> I would like to see the border around the small icons to be thinner.
consider it done. (meaning: good point)
>I
> would also like to see the end of the spear blade to be better defined -
> maybe in a darker colour?
hmm. It is ment to be a lance =). This is a problem as I don't
want to loose contrast between the text and what is behind of
it on low-res monitors.
> >I'd like y'all to pick either the layout
> >in the left or right series, and also the
> >color scheme from left or right (they
> >differ in a subtle way).
>
> Both looked to be different shades of grey to me .. is that what they were
> meant to look like?
Yep. One is rgb(70,70,100) or something, the other
is rgb(80,80,80). Metal has a blueish shading to
it, so I wanted to test if people generally felt that
looked better. So far, most seem to not have a very
expensive monitor like me =)
> >Also, the short slogan in the main logo
> >could be something different...
>
> The problem is associated with our branding - what do we want to
> be branded
> as? Because Avalon used to be much bigger (It incorporated both
> Cornerstone
> and Phoenix) many people associate it with Phoenix. Others associate it
> plainy with framework part ... others the components etc.
see my other e-mail on this...
> A query - what program did you use to create it? (and whats it's native
> format?)
I used CorelDRAW 9, which has a custom native format. Fortunately,
it provides full compatibility with Adobe Illustrator and about
10000 other formats. I use Corel Photo-Paint 9 for the bitmap
retouching (or photoshop when it photo-paint doesn't have a
feature, which doesn't happen often).
greetz,
LSD
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("mail@leosimons.com");
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: back to branding
Posted by Peter Donald <do...@apache.org>.
At 11:48 10/4/01 +1000, Peter Donald wrote:
>Directed Acylic (sp?) Graph - we use it as a dependency graph.
gaah - acyclic
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: back to branding
Posted by Peter Donald <do...@apache.org>.
At 08:47 9/4/01 +0200, Leo Simons wrote:
>> 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.
>
>The current version works pretty well, doesn't it? (ment as a real
>question - I have no idea of any issues there may be)
Issues I see with current version:
* No management interface
* developer orientated logging
* I don't like the fact that .sars are unzipped. (almost fixed in local
version though)
>> >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.
>
>Arguments con:
> - I have yet to think of one, really.
* mixing concerns (namely kernel vs non-kernel implementations) and
considering most people will use non kernel implementation then I think
this is significant.
>> 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 ;)
>
>DVE?
Distributed Virtual Environment (military based most likely)
>Anyway, I think it would help this project tremendously if everyone
>who needs Avalon for something it does not do atm to make those needs
>known to everyone. So, could you elaborate?
I need it capable of being
1. scalable (from low-end clients to high-end servers)
2. runtime loading/unloading (nothing should *ever* go down but must be
able to be reconfigured on the fly).
3. optionally compilable to native code via jet/gcj/other
4. lots of small interacting bits rather than monolithic
5. Solid classpath management
6. Solid security infrastructure (both code based as well as principle based)
7. Fast
Ideally cornerstone will also have some blocks for
a. Role Mapping (ie Does Bob belong to group Administrator?)
b. Authentication
c. Authorisation (ACLs or JAAS style system)
d. Block to manage multicast traffic distribution
Hobbywise I also want to rewrite parts of OS in java. We have
news/telnet/mail/ftp servers in progress but I also want to replace crond
and initd with java based deamons (based on Ant2).
It is getting closer all the time to what I want but there is still a few
kinks to work out.
>To practice what I preach, the only real need I have for Avalon is to
>prove to myself that I can be a real help to an open source project,
>learn how to work in a software development team, and hopefully also
>have something cool to put on my resume =)
don't forget "having fun" ;)
>Things I want to do:
>
>- clean up / simplify phoenix so that it doesn't take weeks to learn
> its internals. Once done doing that, I'll document it too.
excellent
>- I think each lifecycle method (except perhaps dispose()) needs to
> throw its own exception (in the potentially very complex apps built
> on top of Avalon, each method could result in a problem). This needs
> doing, and the exception stuff needs some more documentation as well.
Me too. Add to this the following items and you will have a short-list from
my TODO list ;)
* move init() --> initialize()
* remove Runnable as a lifecycle stage
* Make Context.get() throw an Exception if not found
* Possibly add Mutable versions of Context/Configuration/ComponentManager
interfaces
>- I have ideas on improving the PR/website that I hope to get around
> to before I leave for Down Under.
kewl ;)
>- I would like to see XCommander running on a live server and write
> a chat application (or something similar; real-time) that uses it
> (anyone want to pay for such a server? ;-)
I think something could be arranged if something was operational ;)
>I disagree. Once all interfaces are defined and are stable,
>programming to the interfaces only should be possible. If not,
>the interfaces should not be stable.
We don't have interfaces and factories for Mutable versions of objects. So
components that need to create/modify
configuration/componentmanager/context need to directly manipulate the
Default* objects.
>question: where can I learn about "DAG" (have no idea what it means)?
Directed Acylic (sp?) Graph - we use it as a dependency graph.
Definition basically is;
* a graph with nodes and arcs
* arcs have a direction (ie A->B is not the same as B->A)
* circular dependencies are not allowed (ie A->B->...->A disallowed)
Our nodes are blocks, our arcs include a name of a block and a service it
offers.
>one more: what are the thoughts on the definition of "milestones";
>are we at a stage yet where we can start a 'versioning system' so
>other projects can start depending on that? (it seems like this is
>the right time to think about it and set it up, since we've now
>started talking about "beta" rather than "alpha")
Could be good. I am too lazy to do it and tend to only release stuff when
people bug me enough ;)
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: back to branding
Posted by Leo Simons <ma...@leosimons.com>.
> 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.
Probably. I'd help but I haven't got those multiple environments
to offer. One thing I'd put on my list - if someone explained to
me how to do it - is a load testing/black box testing setup.
> >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.
The current version works pretty well, doesn't it? (ment as a real
question - I have no idea of any issues there may be)
> >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.
Arguments con:
- I have yet to think of one, really.
Arguments pro:
- "I really like the positioning of Phoenix as a RI. This will
help with broader take-up but providing a core engine, stable,
reference sites, etc, - demonstrating and reinforcing the
Avalon best-practice." (as steve put it)
- the specification-with-RI has proven to be quite a successful
"pattern". As Avalon is all about patterns/design, it makes
sense to me that we adopt it.
> 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 ;)
DVE?
Anyway, I think it would help this project tremendously if everyone
who needs Avalon for something it does not do atm to make those needs
known to everyone. So, could you elaborate?
To practice what I preach, the only real need I have for Avalon is to
prove to myself that I can be a real help to an open source project,
learn how to work in a software development team, and hopefully also
have something cool to put on my resume =)
Things I want to do:
- clean up / simplify phoenix so that it doesn't take weeks to learn
its internals. Once done doing that, I'll document it too.
- when I know how it all works, I'll add in JMX capability (I don't
really feel like doing a temporary hack, since others have already
repeatedly expressed a need for JMX, it seems smart to do it right
the first time, to avoid temporary hacks of temporary hacks)
- I think each lifecycle method (except perhaps dispose()) needs to
throw its own exception (in the potentially very complex apps built
on top of Avalon, each method could result in a problem). This needs
doing, and the exception stuff needs some more documentation as well.
- I have ideas on improving the PR/website that I hope to get around
to before I leave for Down Under.
- I would like to see XCommander running on a live server and write
a chat application (or something similar; real-time) that uses it
(anyone want to pay for such a server? ;-)
> >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).
I disagree. Once all interfaces are defined and are stable,
programming to the interfaces only should be possible. If not,
the interfaces should not be stable.
Of course, we'll be at version 7 or 8 before this can become
reality.
> >Ideal setup:
(snip)
> perhaps but thats waaaaay in future - I don't think we should even be
> thinking about it for another 6 months ;)
Agreed...but I like to dream =)
> >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.
when "rapid services development" matures, that separation will
probably dissapate. Anyway, cornerstone also hosts some utils
useful to apps built on top of Avalon, at least it seems that
way to me. Nevermind; doesn't really matter.
question: where can I learn about "DAG" (have no idea what it means)?
one more: what are the thoughts on the definition of "milestones";
are we at a stage yet where we can start a 'versioning system' so
other projects can start depending on that? (it seems like this is
the right time to think about it and set it up, since we've now
started talking about "beta" rather than "alpha")
g'night all!
LSD
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("mail@leosimons.com");
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: back to branding
Posted by Charles Benett <ch...@benett1.demon.co.uk>.
+1 for excalibur
Charles
Peter Donald wrote:
>
> excalibur seems to be the most popular - unless other options jump up I
> will use that ;)
>
> 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: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: back to branding
Posted by Peter Donald <do...@apache.org>.
excalibur seems to be the most popular - unless other options jump up I
will use that ;)
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: back to branding
Posted by Stephen McConnell <mc...@osm.net>.
> merlin: +1.2
> morgana: +1.1
> excalibur: + 1.5
Ummm, changing my mind :-)
excalibur: + 1.5
morgana: +1.4
merlin: +1.2
Steve.
> > -----Original Message-----
> > From: Leo Simons [mailto:mail@leosimons.com]
> > Sent: Monday, 16 April, 2001 10:33
> > To: Avalon Development
> > Subject: RE: back to branding
> >
> >
> > > > I am going to start converting the main tree to have separate
> > > sections for
> > > > components and framework. We still need to decide on a name for the
> > > > component hierarchy (org.apache.???.*). Any
> > > suggestions/recomendations/votes?
> >
> > harmeet:
> > > org.apache.components
> > > or
> > > org.apache.avalon.knights :-)
> >
> > me:
> > > options:
> > >
> > > components
> > > framework
> > > aut
> > > avalondev
> > > more arthurian names:
> > >
> > > merlin
> > > morgana
> > > lancelot
> > > valiant
> > >
> > > castle
> > > sword
> > > lance
> > > dungeon
> > > tower
> > > excalibur
> > >
> > > I like "excalibur" myself.
> >
> > After some more thinking, "dungeon" may be
> > appropriate as well as that hints at the
> > fact that this stuff is less stable.
> >
> > cheers!
> >
> > LSD
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: back to branding
Posted by Stephen McConnell <mc...@osm.net>.
merlin: +1.2
morgana: +1.1
excalibur: + 1.5
> -----Original Message-----
> From: Leo Simons [mailto:mail@leosimons.com]
> Sent: Monday, 16 April, 2001 10:33
> To: Avalon Development
> Subject: RE: back to branding
>
>
> > > I am going to start converting the main tree to have separate
> > sections for
> > > components and framework. We still need to decide on a name for the
> > > component hierarchy (org.apache.???.*). Any
> > suggestions/recomendations/votes?
>
> harmeet:
> > org.apache.components
> > or
> > org.apache.avalon.knights :-)
>
> me:
> > options:
> >
> > components
> > framework
> > aut
> > avalondev
> > more arthurian names:
> >
> > merlin
> > morgana
> > lancelot
> > valiant
> >
> > castle
> > sword
> > lance
> > dungeon
> > tower
> > excalibur
> >
> > I like "excalibur" myself.
>
> After some more thinking, "dungeon" may be
> appropriate as well as that hints at the
> fact that this stuff is less stable.
>
> cheers!
>
> LSD
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: back to branding
Posted by Leo Simons <ma...@leosimons.com>.
> > I am going to start converting the main tree to have separate
> sections for
> > components and framework. We still need to decide on a name for the
> > component hierarchy (org.apache.???.*). Any
> suggestions/recomendations/votes?
harmeet:
> org.apache.components
> or
> org.apache.avalon.knights :-)
me:
> options:
>
> components
> framework
> aut
> avalondev
> more arthurian names:
>
> merlin
> morgana
> lancelot
> valiant
>
> castle
> sword
> lance
> dungeon
> tower
> excalibur
>
> I like "excalibur" myself.
After some more thinking, "dungeon" may be
appropriate as well as that hints at the
fact that this stuff is less stable.
cheers!
LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: back to branding
Posted by Harmeet Bedi <hb...@yahoo.com>.
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
> Hi,
>
> I am going to start converting the main tree to have separate sections for
> components and framework. We still need to decide on a name for the
> component hierarchy (org.apache.???.*). Any
suggestions/recomendations/votes?
org.apache.components
or
org.apache.avalon.knights :-)
Harmeet
>
> At 10:09 12/4/01 +1000, Peter Donald wrote:
> >Hmmm - we aren't any closer to deciding on how to lay this out yet so how
> >about this.
> >
> >* I move camelot+atlantis into phoenix because phoenix is the greatest
user
> >of that stuff and camelot/atlantis is about same stability as phoenix.
> >
> >* org.apache.avalon.* contains the stable framework code, nothing more
> >(currently what is in org.apache.framework in proposal)
> >
> >* org.apache.????.* contains all the components (currently what is in
> >org.apache.avalon.* in proposal minus camelot and atlantis)
> >
> >* we create two new component dirs org.apache.???.concurrency.* (for
> >concurrency stuff), org.apache.???.collection.* (collection utils)
> >
> >* we decide on apropriate name for ???
> >
> >This makes ??? a little cleaner and consistent. What do you think of that
?
> >
> >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: avalon-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
> >
> >
> 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: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: back to branding
Posted by Peter Donald <do...@apache.org>.
Hi,
I am going to start converting the main tree to have separate sections for
components and framework. We still need to decide on a name for the
component hierarchy (org.apache.???.*). Any suggestions/recomendations/votes?
At 10:09 12/4/01 +1000, Peter Donald wrote:
>Hmmm - we aren't any closer to deciding on how to lay this out yet so how
>about this.
>
>* I move camelot+atlantis into phoenix because phoenix is the greatest user
>of that stuff and camelot/atlantis is about same stability as phoenix.
>
>* org.apache.avalon.* contains the stable framework code, nothing more
>(currently what is in org.apache.framework in proposal)
>
>* org.apache.????.* contains all the components (currently what is in
>org.apache.avalon.* in proposal minus camelot and atlantis)
>
>* we create two new component dirs org.apache.???.concurrency.* (for
>concurrency stuff), org.apache.???.collection.* (collection utils)
>
>* we decide on apropriate name for ???
>
>This makes ??? a little cleaner and consistent. What do you think of that ?
>
>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: avalon-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
>
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: back to branding
Posted by Leo Simons <ma...@leosimons.com>.
> Hmmm - we aren't any closer to deciding on how to lay this out yet so how
> about this.
I agree we should settle this...
> * I move camelot+atlantis into phoenix because phoenix is the
> greatest user
> of that stuff and camelot/atlantis is about same stability as phoenix.
Smart thing. The interfaces should probably make it back into the
framework once they get stable, but that is something to think
about later.
> * org.apache.avalon.* contains the stable framework code, nothing more
> (currently what is in org.apache.framework in proposal)
>
> * org.apache.????.* contains all the components (currently what is in
> org.apache.avalon.* in proposal minus camelot and atlantis)
options:
components
framework
aut
avalondev
more arthurian names:
merlin
morgana
lancelot
valiant
castle
sword
lance
dungeon
tower
excalibur
I like "excalibur" myself.
> This makes ??? a little cleaner and consistent. What do you think
> of that ?
as long as the specification ends up in org.apache.avalon.* in
the end and phoenix is maintained as a brand name, I can
definately live with this. I'm still all for the spec-with-RI
model, but I suggest we leave that for later =)
greetz,
LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: back to branding
Posted by Peter Donald <do...@apache.org>.
Hmmm - we aren't any closer to deciding on how to lay this out yet so how
about this.
* I move camelot+atlantis into phoenix because phoenix is the greatest user
of that stuff and camelot/atlantis is about same stability as phoenix.
* org.apache.avalon.* contains the stable framework code, nothing more
(currently what is in org.apache.framework in proposal)
* org.apache.????.* contains all the components (currently what is in
org.apache.avalon.* in proposal minus camelot and atlantis)
* we create two new component dirs org.apache.???.concurrency.* (for
concurrency stuff), org.apache.???.collection.* (collection utils)
* we decide on apropriate name for ???
This makes ??? a little cleaner and consistent. What do you think of that ?
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: back to branding
Posted by Peter Donald <do...@apache.org>.
At 04:01 10/4/01 +0200, Stephen McConnell wrote:
>
>The proposal/org.apache.framework is clean in structure,
>the proposal/org.apache.avalon is not (just try drawing up
>a package dependency graph for proposal/org.apache.avalon and
>you will see what I mean. Bottom line - this is back to the
>question of package naming that we were discussing earlier.
>
>I propose the following:
>
> 1. the current proposal/org.apache.framework be renamed
> to proposal/org.apache.avalon (on the grounds already
> covered in numerous emails relating to brand)
Sounds fine to me.
> 2. that the current proposal/org.apache.avalon be renamed
> to proposal/org.apache.avalon.dev
-1 as it doesn't make sense conceptually
* mixes component and framework aspects
* mixes stable and non-stable aspects
* doesn't make it clearer what dev is supposed to do
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: back to branding
Posted by Stephen McConnell <mc...@osm.net>.
The proposal/org.apache.framework is clean in structure,
the proposal/org.apache.avalon is not (just try drawing up
a package dependency graph for proposal/org.apache.avalon and
you will see what I mean. Bottom line - this is back to the
question of package naming that we were discussing earlier.
I propose the following:
1. the current proposal/org.apache.framework be renamed
to proposal/org.apache.avalon (on the grounds already
covered in numerous emails relating to brand)
2. that the current proposal/org.apache.avalon be renamed
to proposal/org.apache.avalon.dev
Cheers, Steve.
Peter Donald wrote:
> At 04:10 10/4/01 +0200, Stephen McConnell wrote:
> >Have been going through the "proposal" src tree in Avalon
> >(org.apache.avalon and org.apache.framework) with the
> >objective of building up a similar "specification/implementation"
> >diagram to that shown below.
> >After filling up half a page with packages and dependencies I
> >was left with the impression that the proposal structure is
> >substantially less structured that the existing Avalon structure
> >I outline below.
>
> Well I guess you are looking at it from a different angle. The framework
> package (org.apache.framework atm) is something that we go beta with soon.
>
> It contains code that we are 100% willing to support and nothing more.
> While camelot and atlantis fit under the banner of framework they are not
> widely enough applied to be considered 100% stable. Hence they can not go
> beta and thus can not go into that package.
>
> org.apache.avalon.* will eventually hold just components (pools/db
> pools/caches/thread-management etc). Atm it holds a little more
> (processor+camelot+atlantis packages) because they are not stable.
>
> The advantage is that we can now comfortably go beta with
> framework.* so it could be used in other projects like Cocoon2/Ant2/Other
> without any reservations. The components can still safely evolve as
> appropriate while relying on solid base.
>
> 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: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: back to branding
Posted by Peter Donald <do...@apache.org>.
At 04:10 10/4/01 +0200, Stephen McConnell wrote:
>Have been going through the "proposal" src tree in Avalon (org.apache.avalon
>and org.apache.framework) with the objective of building up a similar
>"specification/implementation" diagram to that shown below. After filling
>up half a page with packages and dependencies I was left with the impression
>that the proposal structure is substantially less structured that the
>existing Avalon structure I outline below.
Well I guess you are looking at it from a different angle. The framework
package (org.apache.framework atm) is something that we go beta with soon.
It contains code that we are 100% willing to support and nothing more.
While camelot and atlantis fit under the banner of framework they are not
widely enough applied to be considered 100% stable. Hence they can not go
beta and thus can not go into that package.
org.apache.avalon.* will eventually hold just components (pools/db
pools/caches/thread-management etc). Atm it holds a little more
(processor+camelot+atlantis packages) because they are not stable.
The advantage is that we can now comfortably go beta with framework.* so it
could be used in other projects like Cocoon2/Ant2/Other without any
reservations. The components can still safely evolve as appropriate while
relying on solid base.
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: back to branding
Posted by Stephen McConnell <mc...@osm.net>.
Morning everyone:
(evening Pete :-))
Have been going through the "proposal" src tree in Avalon (org.apache.avalon
and org.apache.framework) with the objective of building up a similar
"specification/implementation" diagram to that shown below. After filling
up half a page with packages and dependencies I was left with the impression
that the proposal structure is substantially less structured that the
existing Avalon structure I outline below. So my assumption is that I'm
missing something fundamental here (perhaps I'm intellectually challenged) -
can anyone fill me in on the advantages of the proposed structure over and
above the existing structure, because the existing structure seems to be
reasonably clean in terms of dependence hierarchy)?
Cheers, Steve.
A little earlier today I wrote:
> Sent: Monday, 09 April, 2001 19:12
> To: Avalon Development
> Subject: RE: back to branding
>
>
>
>
> If you look at the "Avalon" big picture you can cut it into
> "specification" and "implementation". The Specification
> correspond to the Avalon stack shown below on the left. "Phoenix"
> packaged as a RI along the lines Leo suggested makes lots of sense to
> me - but the cornerstone server/demo composition needs a clean-up.
> Repackage cornerstone demos as "Excalibur" and you start to see a
> marketable structure.
>
> Avalon
> ======
>
> Specifciations Implementation
> ============== ==============
>
> |------------------------| |------------------------|
> | | | Excalibur |
> | | |------------------------|
> | avalon.atlantis | <-- | Phoenix |
> |------------------------| | RI implementation |
> | avalon.camalot | |(including Cornerstone |
> |------------------------| | services) |
> | avalon.component | |------------------------|
> |------------------------|
> | avalon.Configuration |
> |------------------------|
> | Avalon |
> |------------------------|
>
>
> I think that the introduction of something more stuctured will
> facilitate a broad level of participation in the process, leading
> to higher recognition and use.
>
> Cheers, Steve.
>
>
> > >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...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: back to branding
Posted by Stephen McConnell <mc...@osm.net>.
If you look at the "Avalon" big picture you can cut it into
"specification" and "implementation". The Specification
correspond to the Avalon stack shown below on the left. "Phoenix"
packaged as a RI along the lines Leo suggested makes lots of sense to
me - but the cornerstone server/demo composition needs a clean-up.
Repackage cornerstone demos as "Excalibur" and you start to see a
marketable structure.
Avalon
======
Specifciations Implementation
============== ==============
|------------------------| |------------------------|
| | | Excalibur |
| | |------------------------|
| avalon.atlantis | <-- | Phoenix |
|------------------------| | RI implementation |
| avalon.camalot | |(including Cornerstone |
|------------------------| | services) |
| avalon.component | |------------------------|
|------------------------|
| avalon.Configuration |
|------------------------|
| Avalon |
|------------------------|
I think that the introduction of something more stuctured will
facilitate a broad level of participation in the process, leading
to higher recognition and use.
Cheers, Steve.
> >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...
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: back to branding
Posted by Peter Donald <do...@apache.org>.
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: back to branding
Posted by Leo Simons <ma...@leosimons.com>.
> >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("mail@leosimons.com");
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: back to branding
Posted by Peter Donald <do...@apache.org>.
At 08:55 6/04/01 +0200, Leo Simons wrote:
>> Because Avalon used to be much bigger (It incorporated both
>> Cornerstone
>> and Phoenix)
>
>Actually, since people perceive Avalon as containing all of this:
Same here ;) I have been gradually been separating things out in this
manner aswell ;)
>- server framework specification
Currently that is
org.apache.avalon.Config*
org.apache.avalon.Comp*
org.apache.avalon.Contex*
org.apache.phoenix.* (Kernel related specification)
>- default framework implementation
org.apache.avalon.DefaulyContex*
org.apache.avalon.DefaulyConfig*
org.apache.avalon.DefaulyComp*
>- reusable components
Kernel level components: org.apache.cornerstone.*/*
Non-Kernel components: org.apache.avalon.util.*/*
>- engine for running framework components
org.apache.phoenix.engine.*
org.apache.phoenix.metainfo.*
>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
>becomes a separate project which also provides a default
>implementation),
Unable to be done as Commons wont accept the Avalon "infected" components.
>this would probably be disastrous to Avalon.
>It would require a new web page, new mailing lists etc to
>provide a separation which isn't there.
I like to think of them as sub-projects of avalon which hopefully wont
affect the brand - what do you think?
>The most logical and clean option while maintaining the strength
>of the Avalon brand, IMHO, would be:
>
>Avalon, Apache Server Framework
>===============================
>- org.apache.avalon - framework specification
> = currently proposed org.apache.framework
> += revised and extended org.apache.framework.atlantis,
> specifying the behaviour of a Kernel, Embeddor,
> and JMX Manager (see /proposal in phoenix cvs
> for descriptions).
Not stable enough yet
> += org.apache.avalon.testsuite against which
> framework implementations are verified. Those
> that pass all tests get to be called "100% Avalon
> Compliant".
good idea
>- org.apache.phoenix - RI of framework aimed at server apps.
> = org.apache.phoenix.* as reference implementation
> of org.apache.avalon, thus the classes currently
> in the proposed org.apache.avalon.
Currently org.apache.phoenix.* is the "specification" along with avalon and
org.apache.phoenix.engine/metainfo is the RI ;)
> += org.apache.phoenix.atlantis becomes an implementation
> and extension of the Kernel, Embeddor and JMX Manager
> interfaces.
Perhaps org.apache.phoenix.engine.atlantis.* ???
> += 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.
>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 ? ;)
>- 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 ;)
>- By extending/cleaning up atlantis, it will become easier for
>others to create an AvalonKernel (i.e. phoenix). Phoenix would
>also be easier to program to, as its interfaces are now set in
>stone. This will allow for example Cocoon to create a
>CocoonKernel which implements AvalonKernel by wrapping around
>PhoenixKernel.
+10000
>- 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? ;)
>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.
> - 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 ;)
>This might take a lot of time, and is certainly not all neccessary
>for version 4 of the framework. Until phoenix is updated as well
>to become the reference implementation of the framework, a temporary
>location for the 'draft' reference implementation could be just about
>anything, like
Sounds like a long term goal ;)
>Proposals:
>----------
>- Avalon remains the main brand for all things related to it,
> while Phoenix is for now a sub-brand of Avalon providing a
> reference implementation of Avalon.
+1
>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 am just taking a slower approach but
have been pushing for many of these things since joining up to Avalon ;)
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: back to branding
Posted by Stephen McConnell <mc...@osm.net>.
Leo Simons [mailto:mail@leosimons.com] wrote:
> > Today Avalon (the brand) represents 1, 2 and 3. In Pete's message
> > he's talking about Avalon in terms of point 1, not in terms of 1..3.
> > I think that maybe we do have a "brand management" problem (wow,
> > actually got in the 'm' word on an open-source list :-)). There
> > are two exit mechanisms here:
>
> I've got another one that models the current setup in many java
> specifications:
[snip]
> 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.
> This will clarify to the world what Avalon is, and also
> strengthen the Phoenix brand. It follows the setup used
> for official java specifications, which has many
> advantages:
> - it will become easier (even transparent) for users
> of Avalon-enabled components to swap implementations
> - likewise, it will be easier to develop a new
> implementation as parts of phoenix are easily re-used.
> - the separation between interface and implementation
> is complete.
> - the model will be similar for anyone who has worked
> with existing java specifications, thus reducing the
> learning curve.
+ 3.5
When discussing marketing or brand management you can always
go beyond a 1 :-). I think Leo has made an excellent proposal.
I really like the positioning of Phoenix as a RI. This will
help with broader take-up but providing a core engine, stable,
reference sites, etc, - demonstrating and reinforcing the
Avalon best-practice.
Steve.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: back to branding
Posted by Leo Simons <ma...@leosimons.com>.
> G'day Pete:
>
> > The problem is associated with our branding - what do we
> > want to be branded as? Because Avalon used to be much bigger
> > (It incorporated both Cornerstone and Phoenix) many people
> > associate it with Phoenix. Others associate it
> > plainy with framework part ... others the components etc.
>
> Today the Avalon "brand" covers three things (and don't hesitate
> to correct or suggest other views), and its in the definition of
> these three things that I think the "branding" question get
> confusing:
>
> 1 "Avalon - the framework stuff"
> 2. "Phoenix - the engine stuff"
> 3 "Cornerstone - the blocks stuff"
>
> Today Avalon (the brand) represents 1, 2 and 3. In Pete's message
> he's talking about Avalon in terms of point 1, not in terms of 1..3.
> I think that maybe we do have a "brand management" problem (wow,
> actually got in the 'm' word on an open-source list :-)). There
> are two exit mechanisms here:
I've got another one that models the current setup in many java
specifications:
> Because Avalon used to be much bigger (It incorporated both
> Cornerstone
> and Phoenix)
Actually, since people perceive Avalon as containing all of this:
- server framework specification
- default framework implementation
- reusable components
- engine for running framework components
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
becomes a separate project which also provides a default
implementation), this would probably be disastrous to Avalon.
It would require a new web page, new mailing lists etc to
provide a separation which isn't there.
It could be there, but it isn't and it is also unlikely to
get here soon.
The most logical and clean option while maintaining the strength
of the Avalon brand, IMHO, would be:
Avalon, Apache Server Framework
===============================
- org.apache.avalon - framework specification
= currently proposed org.apache.framework
+= revised and extended org.apache.framework.atlantis,
specifying the behaviour of a Kernel, Embeddor,
and JMX Manager (see /proposal in phoenix cvs
for descriptions).
+= org.apache.avalon.testsuite against which
framework implementations are verified. Those
that pass all tests get to be called "100% Avalon
Compliant".
- org.apache.phoenix - RI of framework aimed at server apps.
= org.apache.phoenix.* as reference implementation
of org.apache.avalon, thus the classes currently
in the proposed org.apache.avalon.
+= org.apache.phoenix.atlantis becomes an implementation
and extension of the Kernel, Embeddor and JMX Manager
interfaces.
+= org.apache.avalon.demos, the current demos from
cornerstone.
- org.apache.components - library of reusable components
= current org.apache.cornerstone minus demos and not
very reusable code.
- org.apache.log - nothing new here ;)
Notes:
------
- I feel the framework should also define how components/blocks
are handled, and thus define what our current phoenix should
look like.
- 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).
- By extending/cleaning up atlantis, it will become easier for
others to create an AvalonKernel (i.e. phoenix). Phoenix would
also be easier to program to, as its interfaces are now set in
stone. This will allow for example Cocoon to create a
CocoonKernel which implements AvalonKernel by wrapping around
PhoenixKernel.
- 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).
- components is a more clear name than cornerstone, IMHO. Doesn't
matter much though.
- if we wish to define logging of Components in the framework
specifications, then there should indeed be org.apache.avalon.log.
This means phoenix would have org.apache.phoenix.log, which
makes use of LogKit.
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.
This will clarify to the world what Avalon is, and also
strengthen the Phoenix brand. It follows the setup used
for official java specifications, which has many
advantages:
- it will become easier (even transparent) for users
of Avalon-enabled components to swap implementations
- likewise, it will be easier to develop a new
implementation as parts of phoenix are easily re-used.
- the separation between interface and implementation
is complete.
- the model will be similar for anyone who has worked
with existing java specifications, thus reducing the
learning curve.
This might take a lot of time, and is certainly not all neccessary
for version 4 of the framework. Until phoenix is updated as well
to become the reference implementation of the framework, a temporary
location for the 'draft' reference implementation could be just about
anything, like
org.apache.avalon.implementation
org.apache.framework
org.apache.phoenix.implementation
etc etc. Of these, I prefer the first, but Pete likes the second
more because of greater separation between the two, which is also
fine with me.
This leaves the unstable/nonfinished part of the specification.
I suggest using
org.apache.avalon.draft /
org.apache.avalon.dev /
org.apache.avalondev
for that.
Proposals:
----------
- a long-term movement to the structure I've explained above,
for reasons mentioned above.
- if it is not feasible to modify phoenix to be the reference
implementation of the framework in time (i.e. May), put the
reference implementation in org.apache.framework until it is.
- Avalon remains the main brand for all things related to it,
while Phoenix is for now a sub-brand of Avalon providing a
reference implementation of Avalon.
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.
regards,
Leo Simons
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("mail@leosimons.com");
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
back to branding
Posted by Stephen McConnell <mc...@osm.net>.
G'day Pete:
> The problem is associated with our branding - what do we
> want to be branded as? Because Avalon used to be much bigger
> (It incorporated both Cornerstone and Phoenix) many people
> associate it with Phoenix. Others associate it
> plainy with framework part ... others the components etc.
Today the Avalon "brand" covers three things (and don't hesitate
to correct or suggest other views), and its in the definition of
these three things that I think the "branding" question get
confusing:
1 "Avalon - the framework stuff"
2. "Phoenix - the engine stuff"
3 "Cornerstone - the blocks stuff"
Today Avalon (the brand) represents 1, 2 and 3. In Pete's message
he's talking about Avalon in terms of point 1, not in terms of 1..3.
I think that maybe we do have a "brand management" problem (wow,
actually got in the 'm' word on an open-source list :-)). There
are two exit mechanisms here:
1. rename "Avalon the framework stuff" to something
new and exciting then update everything so that the
common message is that...
Avalon (the brand) is:
"XXXXXX - the framework stuff"
"Phoenix - the engine stuff"
"Cornerstone - the block stuff"
2. or, we redefine Avalon as the framework stuff and
escalate Phoenix (possible) as its own entity, and
figure out what to do with Cornerstone.
I don't like option (2) because of this will fragment the brand
value currently established (and keep in mind that what is currently
established is fragile but recognisable - and remember that getting
to recognisable is a way-cool achievement).
Cheers, Steve.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Avalon logo...
Posted by Peter Donald <do...@apache.org>.
At 12:13 5/04/01 +0200, you wrote:
>I've now got three designs which I like.
They look slick !
>I propose using the one at the bottom as
>the main logo, and the series on the right
>in places where that is too big or a
>more compact logo is simply more desireable.
+1 to left though both are good ;)
I would like to see the border around the small icons to be thinner. I
would also like to see the end of the spear blade to be better defined -
maybe in a darker colour?
>I'd like y'all to pick either the layout
>in the left or right series, and also the
>color scheme from left or right (they
>differ in a subtle way).
Both looked to be different shades of grey to me .. is that what they were
meant to look like?
>Also, the short slogan in the main logo
>could be something different...
The problem is associated with our branding - what do we want to be branded
as? Because Avalon used to be much bigger (It incorporated both Cornerstone
and Phoenix) many people associate it with Phoenix. Others associate it
plainy with framework part ... others the components etc.
>finally, should there be a "v3" and/or
>"v4" tag somewhere in the logo?
Naah as different parts are dfferent versions. The kernel is in it's 5th
revision, the framework is version 3.x, logkit is in it's first revision etc.
>When these last issues are sorted out,
>I will create logos in sizes
> 16x16
> 32x32
> 128x128 (icons)
>and with heights
> 320
> 800
>and make available the .cdr/.ai and
>fonts I used in the logo.
>
>sounds good?
A query - what program did you use to create it? (and whats it's native
format?)
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Avalon logo...
Posted by Stephen McConnell <mc...@osm.net>.
My prefs:
Layout preference: LEFT
Colour scheme: RIGHT
Text: "Apache Server Framework"
Version: yes, but only as an addition graphic (i.e. don't
exclude a non-version version)
Cheers, Steve.
> -----Original Message-----
> From: Leo Simons [mailto:mail@leosimons.com]
> Sent: Thursday, 05 April, 2001 12:13
> To: Avalon Development
> Subject: RE: Avalon logo...
>
>
> I've now got three designs which I like.
>
> I propose using the one at the bottom as
> the main logo, and the series on the right
> in places where that is too big or a
> more compact logo is simply more desireable.
>
> I'd like y'all to pick either the layout
> in the left or right series, and also the
> color scheme from left or right (they
> differ in a subtle way).
>
> Also, the short slogan in the main logo
> could be something different...
>
> "Apache's Server Framework"
> "Apache Server Framework"
> "Java Server Framework"
> "Apache's Java Server Framework"
> "Java Application Framework"
> "Big balls of fire"
>
> or something else. Are there any other
> suggestions, or should I leave it as it
> is now?
>
> finally, should there be a "v3" and/or
> "v4" tag somewhere in the logo?
>
> When these last issues are sorted out,
> I will create logos in sizes
> 16x16
> 32x32
> 128x128 (icons)
> and with heights
> 320
> 800
> and make available the .cdr/.ai and
> fonts I used in the logo.
>
> sounds good?
>
> LSD, who really needs a better karma...
>
> <java:sig>
> About LSD = new PersonalInfo();
> LSD.name("Leo Simons");
> LSD.email("mail@leosimons.com");
> 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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Avalon logo...
Posted by Jon Stevens <jo...@latchkey.com>.
on 4/5/01 3:13 AM, "Leo Simons" <ma...@leosimons.com> wrote:
> "Apache's Server Framework"
> "Apache Server Framework"
> "Java Server Framework"
> "Apache's Java Server Framework"
> "Java Application Framework"
> "Big balls of fire"
FYI, you can't use the word "Java" in the name. That is why java.apache.org
is dead. Sun owns the trademark.
Personally, I really like the logo with the lance in it the most.
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Avalon logo...
Posted by Leo Simons <ma...@leosimons.com>.
I've now got three designs which I like.
I propose using the one at the bottom as
the main logo, and the series on the right
in places where that is too big or a
more compact logo is simply more desireable.
I'd like y'all to pick either the layout
in the left or right series, and also the
color scheme from left or right (they
differ in a subtle way).
Also, the short slogan in the main logo
could be something different...
"Apache's Server Framework"
"Apache Server Framework"
"Java Server Framework"
"Apache's Java Server Framework"
"Java Application Framework"
"Big balls of fire"
or something else. Are there any other
suggestions, or should I leave it as it
is now?
finally, should there be a "v3" and/or
"v4" tag somewhere in the logo?
When these last issues are sorted out,
I will create logos in sizes
16x16
32x32
128x128 (icons)
and with heights
320
800
and make available the .cdr/.ai and
fonts I used in the logo.
sounds good?
LSD, who really needs a better karma...
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("mail@leosimons.com");
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>
Re: Avalon logo...
Posted by Charles Benett <ch...@benett1.demon.co.uk>.
Berin Loritsch wrote:
>
> Leo Simons wrote:
> >
> > ...I've tried to incorporate all your suggestions and
> > made some new logo. These are very simple and print
> > well in b/w.
> >
> > comments?
>
> I like the lighter background and darker text better than
> the dark background and white text.
+1
> The three I like the
> best are the one in the upper right hand corner, the one
> second from the left in the second row, and the last one
> in the second row. Out of the three, I would have to
> toss a coin between the first two I mentioned.
>
> I like the upper left because it looks neat, but you don't
> get Avalon from "Server Framework".
>
My first choice would be the second from right on the second row,
followed by the second from left on the second row. The upper right
could also work if the text was Avalon rather than Server Framework
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Avalon logo...
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
>
> ...I've tried to incorporate all your suggestions and
> made some new logo. These are very simple and print
> well in b/w.
>
> comments?
I like the lighter background and darker text better than
the dark background and white text. The three I like the
best are the one in the upper right hand corner, the one
second from the left in the second row, and the last one
in the second row. Out of the three, I would have to
toss a coin between the first two I mentioned.
I like the upper left because it looks neat, but you don't
get Avalon from "Server Framework".
>
> Leo
>
> <java:sig>
> About LSD = new PersonalInfo();
> LSD.name("Leo Simons");
> LSD.email("mail@leosimons.com");
> 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>
>
> ------------------------------------------------------------------------------------------------------------------------------------
> Name: sketches2.gif
> sketches2.gif Type: GIF Image (image/gif)
> Encoding: base64
>
> ------------------------------------------------------------------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org