Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
From: "Leo Sutic" <leo.sutic@inspireinfrastructure.com>
To: "'Avalon Developers List'" <avalon-dev@jakarta.apache.org>
Subject: RE: [proposal] avalon 5 ComponentManager interface
Date: Mon, 10 Jun 2002 11:01:50 +0200
Message-ID: <000e01c2105d$7617f640$0801a8c0@Lagrange>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <1023697319.1615.95.camel@lsd.bdv51>
Importance: Normal


> From: Leo Simons [mailto:leosimons@apache.org] 
> 
> Summary:
> 
> - proposal for component management in avalon 5:
> 1) removal of ComponentSelector
> 2) removal of release()

Without including in the proposal a replacement for CS when it
operates on Objects (such as when selecting components based
on a ServletRequest), and a replacement for release() that can
handle switching between pooled and non-pooled components without
any changes to the client code, I can not vote for this proposal.

------------------------

All ComponentManagers should support hints, or none. We're not
making the developers any favors by introducing yet another
"this should work, but then again it might not". A good explanation
of why this is bad exists at:

    http://www.lurkertech.com/linuxvideoio.html

    "If a video I/O API does not offer a common set of scales, 
    formats, aspects, and crops which are guaranteed to work on 
    all devices, you can have all the query mechanisms in the 
    world but it does an app no good. Think about it -- what 
    is the app supposed to do when you plant it on a machine 
    which supports only some new format? Spontaneously sprout 
    new code to handle the format?"

The need for hints exist because we have decided that the
role should be an interface name. To specify more, we can
tack stuff on to the interface name (MyComponent.ROLE + 
"/somehint/anotherhint"), but I consider that uglier than
allowing for a separate hint parameter.

Also, with just String hints, if you use a ServletRequest as
hint, you end up with:

  lookup (role, stringifyRequest (request))

I have no problem with the role being a String, and the hint
being an Object, as we have fixed the role to be an interface
name (and thus a String), while we have not fixed the hint in
the same way.

------------------------

The 

  if (exists (role)) manager.lookup (role)

construct should only be required when the role you are looking
up is optional. That is, the exists() call works just like
hasComponent(). (This would be similar to the use of 
FileNotFoundException - if you are uncertain whether the file exists
you should call exists() before opening, but if it is required
to exist, you can just try to open it.) I question the assertion
that the use of exists() as you propose is common java practice.
I also question that it results in more performant code, as you
do not pay for exceptions unless they are thrown (See
http://java.sun.com/javaone/javaone2001/pdfs/2696.pdf , page 29
for exception handling.) - thus you have traded a lookup that 
should not fail except in exceptional circumstances for a check 
*and* a lookup. 

Please justify these assumptions.

/LS


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