Honest Opinion, Take it for what its worth

[Berin Loritsch <bl...@d-haven.org>]

Avalon needs a future, and there are a number of possibilities ahead that will
really make things work nicely.  This is not a bad situation to be in.  I
remember in the past that we considered Avalon 5 to be synonimous with Java 1.5.
There would be enough in the core language that we wouldn't have to rely on
hacked together utilities that make using Avalon less appealing.

Avalon 4 today fits a certain number of needs, and that is great.  Evolution is
better than revolution in many respects.  I think that is a perfectly natural
way to move forward.  But think about it, in Avalon 4 there is a bunch of cruft.
It would be best to get rid of that cruft.  So a fresh Avalon 5 approach does
not mean coming up with all new interfaces for what you need to do.  It means
that you should trim the fat and work from there.  In doing this, you can remove
all the ties that bind you to those undocumented or back-compatibility traps
that add to the bulk and complexity of the current crop of containers.

This is the first step of simplification.  Tell me if I am wrong if that does
not simplify the tool requirements.

Once we have cut to the core of what we need (no cruft), we can then focus on
what we plan on enforcing.  In the corner of meta-data/meta-info/
meta-whatever-you-want-to-call-it, I highly recommend you to read the docs for
the new Java Annotations features.  You will find that there are different types
of annotations that are important.  You cannot know what they are until you
start playing with them.  For the lazy:

1) Runtime annotations that are necessary to access using reflection on live
    objects.

2) Class annotations that are necessary to access using tools like code
    generators, IDE integration, etc.  These are embedded in the class file,
    but not necessarily accessible through normal reflection.

3) Source annotations that the compiler generally ignores.  They are good for
    documentation purposes, but little more.

Currently, all of the Avalon Meta project falls into the first class of
annotations because they are accessed at runtime and remain in system memory
during runtime.  Some of those should probably be put into class annotations,
or something along those lines.

Lastly, in the process of generating your tools and working with the system,
you don't really know what meta info is going to be helpful to you until you
start playing with it and get the "wouldn't it be nice if..." process going on.
With things so hard coded at the moment, you can't really experiment nicely.
This is the main reason for pushing the Java 1.5 annotations that I have.  Sure
you can define the set of annotations for Avalon 5 and make that part of the
framework.  I would really prefer it if you did.  You still have a well defined
set of contracts, but you also have some room to expand to support different
tools.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

RE: GUIApp (was Re: Honest Opinion, Take it for what its worth)

[Alex Karasulu <ao...@bellsouth.net>]

> What is relevant to Avalon though is that more and more the configuration
> file
> formats lend a great deal to the perceived complexity of the containers.
> As
> LSD has been good to point out, too much magic is not good.  Sylvain put
> it best
> as "Too much magic spoils the confidence".  If you can't readily see how
> something maps at a glance, you tend not to trust it.
> 
> Perhaps a lesson for moving forward...

Noted this is another area where we can re-factor in simplification.  But
the complexity to configurations you speak about has to do with where a
container keeps it right because the content of the config is essentially
determined by a component.  The nature of the component determines the
perceived complexity of the configuration.  Take the data source component
whose config looks messy and complex verses the thread manager component.
One looks more complex than the other.

However again I think you were referring to how the container deals with the
placement and handling of configurations.  

We need to capture all this in one place to make a good list of areas of
potential improvement.

Alex



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

GUIApp (was Re: Honest Opinion, Take it for what its worth)

[Berin Loritsch <bl...@d-haven.org>]

Alex Karasulu wrote:

> BTW I wound up using Merlin and my copy of the event bus instead because of 
> time constraints to build a GUI.  I really wanted the custom lifecycle you 
> have to snap in a component onto the event bus.  I would like to see these 
> kinds of features made as pluggable aspects to Merlin.  The GUI app stuff 
> seemed a little too new and complex for me or at least too complex for me 
> to understand within a couple of hours.  But I do intend to focus more on
> it in the near future: I have not given up.  There are some excellent 
> concepts there for those that want to make their GUI components real 
> components in the Avalon sense.

The most complex part of GUIApp is really the config file.  It doesn't map
logically to the way a Swing GUI person would think.  That is enforced somewhat
due to the way Fortress reads in the configuration, so I am thinking about how
to improve that in the future.  But specifics about GUIApp belong on the d-haven
list.

What is relevant to Avalon though is that more and more the configuration file
formats lend a great deal to the perceived complexity of the containers.  As
LSD has been good to point out, too much magic is not good.  Sylvain put it best
as "Too much magic spoils the confidence".  If you can't readily see how
something maps at a glance, you tend not to trust it.

Perhaps a lesson for moving forward...


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

RE: Honest Opinion, Take it for what its worth

[Alex Karasulu <ao...@bellsouth.net>]

> plan.  Oh, and BTW, I want to have the option to embed my configuration
> file
> inside a JAR so users can't tweek it and mess things up--that is very
> important
> for Swing based applications that GUIApp supports.

BTW I wound up using Merlin and my copy of the event bus instead because of 
time constraints to build a GUI.  I really wanted the custom lifecycle you 
have to snap in a component onto the event bus.  I would like to see these 
kinds of features made as pluggable aspects to Merlin.  The GUI app stuff 
seemed a little too new and complex for me or at least too complex for me 
to understand within a couple of hours.  But I do intend to focus more on
it in the near future: I have not given up.  There are some excellent 
concepts there for those that want to make their GUI components real 
components in the Avalon sense.

Alex




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: Honest Opinion, Take it for what its worth

[Berin Loritsch <bl...@d-haven.org>]

Niclas Hedhman wrote:

> On Friday 05 March 2004 05:17, Berin Loritsch wrote:
> 
>>This is the first step of simplification.  Tell me if I am wrong if that
>>does not simplify the tool requirements.
> 
> if "that" == "trimming fat"  then Agree

You agree then.

>>In the corner of meta-data/meta-info/ meta-whatever-you-want-to-call-it
> 
> I have the feeling that this is already to far away a concern at this point to 
> talk about implementation features, when Vision, Mission and Purpose is not 
> solidly established.

I was merely using this as an example of a type of trimming the fat to get rid
of some of the utility libraries where a better alternative already exists.
The memory footprint and dependency footprint should be kept as small as
possible, but that is my oppinion.

>>Sure you can define the set of annotations for
>>Avalon 5 and make that part of the framework.  I would really prefer it if
>>you did.  You still have a well defined set of contracts, but you also have
>>some room to expand to support different tools.
> 
> I read in this "Framework" as a variant of "AF4", which IMHO is an utterly 
> incomplete Component Contract (proof? >=4 incompatible containers).
> If Avalon is not stepping up the ambition to be Component Oriented, and keep 
> being "Framework Oriented", then I think we don't have a Purpose, definately 
> not a Vision.

I hear your concerns.  Now, the biggest thing that is an obstacle to
compatibility has to do with configuration at this point.  I lump context entry
mapping, configuration specification, and parameters in together under the
configuration front.

If all the containers were able to agree on one configuration file format, and
one way to specify where that configuration file lives, then we have a game
plan.  Oh, and BTW, I want to have the option to embed my configuration file
inside a JAR so users can't tweek it and mess things up--that is very important
for Swing based applications that GUIApp supports.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: Honest Opinion, Take it for what its worth

[Niclas Hedhman <ni...@hedhman.org>]

On Friday 05 March 2004 05:17, Berin Loritsch wrote:
> Avalon needs a future

Pronto!

> It means that you should trim the fat and work from there.  

Agree. "We have landed on the beach, burnt the ship. Move forward."

> This is the first step of simplification.  Tell me if I am wrong if that
> does not simplify the tool requirements.

if "that" == "trimming fat"  then Agree
if "that" == "any simplification" then Not Agree.

> In the corner of meta-data/meta-info/ meta-whatever-you-want-to-call-it

I have the feeling that this is already to far away a concern at this point to 
talk about implementation features, when Vision, Mission and Purpose is not 
solidly established.

> Sure you can define the set of annotations for
> Avalon 5 and make that part of the framework.  I would really prefer it if
> you did.  You still have a well defined set of contracts, but you also have
> some room to expand to support different tools.

I read in this "Framework" as a variant of "AF4", which IMHO is an utterly 
incomplete Component Contract (proof? >=4 incompatible containers).
If Avalon is not stepping up the ambition to be Component Oriented, and keep 
being "Framework Oriented", then I think we don't have a Purpose, definately 
not a Vision.


Cheers
Niclas
-- 
+---------//-------------------+
|   http://www.bali.ac         |
|  http://niclas.hedhman.org   |
+------//----------------------+

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org