avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Simons" <m...@leosimons.com>
Subject RE: back to branding
Date Mon, 09 Apr 2001 18:47:17 GMT
> 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


Mime
View raw message