[POLL] Where does people stand?

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

Please indicate you stance on the following issues, since I am currently 
completely lost in what we want. These are issues that are close to /my/ 
heart. Feel free to add to your own to the list.

Components are more than code.
[ ] Correct
[ ] Incorrect


Components should come in "a box", dropped in place and used without even need 
to look at it.
[ ] Correct
[ ] Incorrect


Simplicity for Component User more important than simplicity for Container 
Developer.
[ ] Correct
[ ] Incorrect


Simplicity for Component Author more important than simplicity for Container 
Developer.
[ ] Correct
[ ] Incorrect


Simplicity for Component User more important than simplicity for Component 
Author.
[ ] Correct
[ ] Incorrect


Without a large Component Repository, COP is pretty meaningless.
[ ] Correct
[ ] Incorrect


COP is not the same as Java classes defined over an API. I.e. just because you 
can instantiate it, doesn't mean it is a Component.
[ ] Correct
[ ] Incorrect


Avalon is about a domain-neutral server framework.[1][2]
[ ] Correct
[ ] Incorrect


Components should be runtime replacable. A true server doesn't need restart.
[ ] Correct
[ ] Incorrect


Avalon-compliant Components could be made to work in non-Avalon-compliant 
containers, effectively running as POJOs, by the Component Author.
[ ] Correct
[ ] Incorrect


These are values that I carry dearly, without mentioning any approach, design 
or implementation aspects of our community. As you may understand, they are 
all formulated in such a way I will answer "Correct" to all of them

I would also appreciate that no elaboration is given in the response mail, 
just to keep it clean. Post those separately.


Cheers
Niclas


[1] http://avalon.apache.org/community/history/call-to-vote.html
[2] http://avalon.apache.org/community/history/what-is-a-server.html

-- 
+---------//-------------------+
|   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

Re: [POLL] Where does people stand?

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

Niclas Hedhman wrote:
> Please indicate you stance on the following issues, since I am currently 
> completely lost in what we want. These are issues that are close to /my/ 
> heart. Feel free to add to your own to the list.
> 
> Components are more than code.
  [X] Correct
> 
> Components should come in "a box", dropped in place and used without even need 
> to look at it.
  [X] Sometimes

Depends on the situation.

> Simplicity for Component User more important than simplicity for Container 
> Developer.
  [X] Correct

NOTE: within limits.

> Simplicity for Component Author more important than simplicity for Container 
> Developer.
  [X] Correct

NOTE: Again, within limits

> Simplicity for Component User more important than simplicity for Component 
> Author.
   [X] Huh?

Seriosuly, it should be just as easy to use a component as it is to write it.
It shouldn't be that hard.  Its a wash.

> Without a large Component Repository, COP is pretty meaningless.
  [X] Incorrect

COP has more value as a way to manage change within an application.  Every
push to create the large component repository has failed.  The latest form
is the Web Services approach, and that seems like it would be a better bet.
That said, COP is more useful than just services and prepackaged components.
Yes you can increase your reuse (you can't ever achieve 100% reuse), but
there is value and meaning to COP outside of the already available components.

> COP is not the same as Java classes defined over an API. I.e. just because you 
> can instantiate it, doesn't mean it is a Component.
  [X] Correct

> Avalon is about a domain-neutral server framework.[1][2]
  [X] Correct

NOTE: We should make it as easy as possible for the current domains that it is
already used.

> Components should be runtime replacable. A true server doesn't need restart.
  [X] Correct

NOTE: Not as a requirement, but as a feature.

> Avalon-compliant Components could be made to work in non-Avalon-compliant 
> containers, effectively running as POJOs, by the Component Author.
  [X] Huh?

What is a POJO?  I don't get it.  Of course the reverse is true as well.  As
long as you have the proper factory to start up the component, any container
can run any type of component.  It's not hard.  Should Avalon tools be
restricted to Avalon components?  I would say so.  But it would be bad if we
cannot run components designed for other frameworks just because.

> These are values that I carry dearly, without mentioning any approach, design 
> or implementation aspects of our community. As you may understand, they are 
> all formulated in such a way I will answer "Correct" to all of them

Yes, but I can't as they are written.  I would answer "Correct" for many as you
saw, but at the same time there are some fundamental differences of oppinion.

> I would also appreciate that no elaboration is given in the response mail, 
> just to keep it clean. Post those separately.

Sorry.  Elaboration is kept small though.


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

RE: Where does people stand?

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

Number of X's up to 5 shows the intensity of belief lack of any is a lack of
belief in anything.

> Components are more than code.
> [ ] Correct
> [ ] Incorrect

I'd rather say components should be POJO's or beans.  Where this falls under
your poll I get confused but trying to get in your head I think you're
asking if components should be Plain Old Java Objects right?  If so I say
yes.  But the reality is no.

> Components should come in "a box", dropped in place and used without even
> need to look at it.
> [X] Correct
> [ ] Incorrect

Call me when you find anything meeting this panacea.  I don't think it
exists - hope it will one day.

> Simplicity for Component User more important than simplicity for Container
> Developer.
> [XXXXX] Correct
> [ ] Incorrect

I emphatically believe in it!

> Simplicity for Component Author more important than simplicity for
> Container
> Developer.
> [XXXXX] Correct
> [ ] Incorrect

I emphatically believe in this too!

> Simplicity for Component User more important than simplicity for Component
> Author.
> [XXX] Correct
> [ ] Incorrect

Again I agree strongly

> Without a large Component Repository, COP is pretty meaningless.
> [ ] Correct
> [ ] Incorrect

Don't know about this need to think it over a bit.  It seems like too strong
of a statement right now.

> COP is not the same as Java classes defined over an API. I.e. just because
> you
> can instantiate it, doesn't mean it is a Component.
> [X] Correct
> [X] Incorrect

COP considers organization and services built on these components.
Component can be a POJO too I feel.

> Avalon is about a domain-neutral server framework.[1][2]
> [XXX] Correct
> [ ] Incorrect


> Components should be runtime replacable. A true server doesn't need
> restart.
> [XX] Correct
> [ ] Incorrect

Nice feature but not a must have.

> Avalon-compliant Components could be made to work in non-Avalon-compliant
> containers, effectively running as POJOs, by the Component Author.
> [ ] Correct
> [ ] Incorrect

The other direction is much easier actually.  

POJO + Wrapper -> Avalon Component

This is how I'm building Eve.  I'm not going to deal with another container
switch so I'm making Eve components all POJOs and container neutral with the
primary container of choice being Merlin.  But wrappers can be made for each
project.  Take a look at this SVN structure document here:

http://incubator.apache.org/directory/subprojects/eve/source-layout.html

here's more on the COP approach:

http://incubator.apache.org/directory/subprojects/eve/components.html

> These are values that I carry dearly, without mentioning any approach,
> design

Same here but there should always be room for new ideas and it's a great
skill to sit back and really listen.  I've learned so much but finally at
the age of 30 figuring out just how to do that.  You guys are gods to me and
playing at Avalon is like being on Olympus.  Let's keep it fun.

> or implementation aspects of our community. As you may understand, they
> are
> all formulated in such a way I will answer "Correct" to all of them
> 
> I would also appreciate that no elaboration is given in the response mail,
> just to keep it clean. Post those separately.

OOooops ok I'll send this out and re-respond with the [POLL] in it.  You
should have said this in the beginning.

Alex





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

RE: [POLL] Where does people stand?

[Leo Sutic <le...@inspireinfrastructure.com>]

Of course, as many have noticed, this is a very low-precision
way of explaining your position, but I hope it will average 
out in the end...

A more verbose answer follows below my quick answers.

> From: Niclas Hedhman [mailto:niclas@hedhman.org] 
>
> Components are more than code.
> [X] Correct
> [ ] Incorrect
> 
> 
> Components should come in "a box", dropped in place and used 
> without even need 
> to look at it.
> [X] Correct
> [ ] Incorrect
> 
> 
> Simplicity for Component User more important than simplicity 
> for Container 
> Developer.
> [X] Correct
> [ ] Incorrect
> 
> 
> Simplicity for Component Author more important than 
> simplicity for Container 
> Developer.
> [X] Correct
> [ ] Incorrect
> 
> 
> Simplicity for Component User more important than simplicity 
> for Component 
> Author.
> [X] Correct
> [ ] Incorrect
> 
> 
> Without a large Component Repository, COP is pretty 
> meaningless. [ ] Correct [X] Incorrect
> 
> 
> COP is not the same as Java classes defined over an API. I.e. 
> just because you 
> can instantiate it, doesn't mean it is a Component.
> [ ] Correct
> [X] Incorrect
> 
> 
> Avalon is about a domain-neutral server framework.[1][2]
> [X] Correct
> [ ] Incorrect
> 
> 
> Components should be runtime replacable. A true server 
> doesn't need restart. [X] Correct [ ] Incorrect
> 
> 
> Avalon-compliant Components could be made to work in 
> non-Avalon-compliant 
> containers, effectively running as POJOs, by the Component 
> Author. [X] Correct [ ] Incorrect


VERBOSE SECTION
---------------

> Components are more than code.
> [X] Correct
> [ ] Incorrect

Can be more than code, but they don't *have* to be.
 
> Components should come in "a box", dropped in place and used 
> without even need to look at it.
> [X] Correct
> [ ] Incorrect

Ideally, yes. But we should not limit the box design by *requiring*
a certain component packaging.

You make me think of .sar or .war files, which are not always the
right way to deploy things.

However, if you *want* to deploy your components like .war or .sar
files, the framework should not make it impossible.

> Simplicity for Component User more important than simplicity 
> for Container Developer.
> [X] Correct
> [ ] Incorrect
> 
> 
> Simplicity for Component Author more important than 
> simplicity for Container Developer.
> [X] Correct
> [ ] Incorrect
> 
> 
> Simplicity for Component User more important than simplicity 
> for Component Author.
> [X] Correct
> [ ] Incorrect

No further comment needed. The above is obvious.
 
> Without a large Component Repository, COP is pretty 
> meaningless. [ ] Correct [X] Incorrect

COP gives you an architectural framework that is very
useful even if you have to write all your components yourself.

> COP is not the same as Java classes defined over an API. I.e. 
> just because you 
> can instantiate it, doesn't mean it is a Component.
> [ ] Correct
> [X] Incorrect

That depends on the component framework. For Avalon, the answer
is "Correct" but for COP the answer is "Incorrect".

> Avalon is about a domain-neutral server framework.[1][2]
> [X] Correct
> [ ] Incorrect
> 
> 
> Components should be runtime replacable. A true server 
> doesn't need restart. [X] Correct [ ] Incorrect

Ideally yes.

A component framework should not by design make runtime-replacement
an impossibility. But it should not require that components are
coded for it.
 
> Avalon-compliant Components could be made to work in 
> non-Avalon-compliant 
> containers, effectively running as POJOs, by the Component 
> Author. [X] Correct [ ] Incorrect

In effect, an Avalon component running in a container is a POJO.

/LS


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

RE: [POLL] Where does people stand?

[Andreas Oberhack <de...@softwarefabrik.biz>]

> Please indicate you stance on the following issues, since I am
currently
> completely lost in what we want. These are issues that are close to
/my/
> heart. Feel free to add to your own to the list.
> 
> Components are more than code.
> [x] Correct
> [ ] Incorrect
> 
> 
> Components should come in "a box", dropped in place and used without
even
> need
> to look at it.
> [x] Correct
> [ ] Incorrect
> 
> 
> Simplicity for Component User more important than simplicity for
Container
> Developer.
> [x] Correct
> [ ] Incorrect
> 
> 
> Simplicity for Component Author more important than simplicity for
> Container
> Developer.
> [x] Correct
> [ ] Incorrect
> 
> 
> Simplicity for Component User more important than simplicity for
Component
> Author.
> [x] Correct
> [ ] Incorrect
> 
> 
> Without a large Component Repository, COP is pretty meaningless.
> [ ] Correct
> [x] Incorrect
> 
> 
> COP is not the same as Java classes defined over an API. I.e. just
because
> you
> can instantiate it, doesn't mean it is a Component.
> [ ] Correct
> [x] Incorrect
> 
> 
> Avalon is about a domain-neutral server framework.[1][2]
> [x] Correct
> [ ] Incorrect
> 
> 
> Components should be runtime replacable. A true server doesn't need
> restart.
> [x] Correct
> [ ] Incorrect
> 
> 
> Avalon-compliant Components could be made to work in
non-Avalon-compliant
> containers, effectively running as POJOs, by the Component Author.
> [x] Correct
> [ ] Incorrect
> 
> 
> These are values that I carry dearly, without mentioning any approach,
> design
> or implementation aspects of our community. As you may understand,
they
> are
> all formulated in such a way I will answer "Correct" to all of them
> 
> I would also appreciate that no elaboration is given in the response
mail,
> just to keep it clean. Post those separately.
> 
> 
> Cheers
> Niclas
> 
> 
> [1] http://avalon.apache.org/community/history/call-to-vote.html
> [2] http://avalon.apache.org/community/history/what-is-a-server.html
> 
> --
> +---------//-------------------+
> |   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



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

RE: [POLL] Where does people stand?

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

Niclas,

You're forcing me into making cookie cutter statements that don't 
tell the whole story or how indecisive I am.  On several questions 
I was undecided but because of a slight (and by slight I mean by 
the weight of a single strand of hair) lean of the balance towards 
one option I voted.  Please consider the detailed explanations in my 
first email without the [POLL] in it.  Do so if you truly consider 
what I have to say.  But I did want to entertain your wishes 
and have replied according to your poll and so without further 
commentary here are the results:


> Components are more than code.
> [X] Correct
> [ ] Incorrect


> Components should come in "a box", dropped in place and used without even
> need
> to look at it.
> [X] Correct
> [ ] Incorrect


> Simplicity for Component User more important than simplicity for Container
> Developer.
> [X] Correct
> [ ] Incorrect


> Simplicity for Component Author more important than simplicity for
> Container
> Developer.
> [X] Correct
> [ ] Incorrect


> Simplicity for Component User more important than simplicity for Component
> Author.
> [X] Correct
> [ ] Incorrect


> Without a large Component Repository, COP is pretty meaningless.
> [ ] Correct
> [X] Incorrect


> COP is not the same as Java classes defined over an API. I.e. just because
> you
> can instantiate it, doesn't mean it is a Component.
> [X] Correct
> [ ] Incorrect


> Avalon is about a domain-neutral server framework.[1][2]
> [X] Correct
> [ ] Incorrect


> Components should be runtime replacable. A true server doesn't need
> restart.
> [X] Correct
> [ ] Incorrect


> Avalon-compliant Components could be made to work in non-Avalon-compliant
> containers, effectively running as POJOs, by the Component Author.
> [X] Correct
> [ ] Incorrect

I'm curious now to see you're results.

Alex



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

RE: Where does people stand?

["Noel J. Bergman" <no...@devtech.com>]

I took off the [POLL] from this since I'm including actual text response to
discuss your points.  I've removed points for which I had neither comment
nor disagreement.

> Components are more than code.

As a friend of mine is wont to say, it all comes down to 1s and 0s in the
end.  So unless you mean documentation, it is all code.  Design doesn't
matter unless it is reflected in code, since computers can't run design.
Meta-data is just a form of code, since something gets executed.

> Components should come in "a box", dropped in place and used without even
need
> to look at it.

Depends upon the level of discourse.

> Without a large Component Repository, COP is pretty meaningless.

I think that's a little strong.  But the stronger the library, the more
compelling and inviting the solution.

> Components should be runtime replacable. A true server doesn't need
restart.

Ideally, yes.  Few systems are quite so nice in practice.

> Avalon-compliant Components could be made to work in non-Avalon-compliant
> containers, effectively running as POJOs, by the Component Author.

That depends upon their other dependencies, e.g., Avalon lifecycle
interfaces, ties to other Avalon interfaces and components, etc.

On the flip-side of your comment, I do believe that we should be looking at
the re-use of other components, that fit your "POJO" description, within
Avalon through the use of adapters.  Avalon need not write and maintain its
own configuration, logging, pooling, etc., implementations if it can cleanly
adapt those from other projects in those domains.

	--- Noel


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