> > > > I HATE the ComponentSelector interface and think it is a huge
> > > > mistake to use it. If the ComponentSelector is simply access to a
> > > > category of avalon components then I can't see why you
> > can't depend
> > > > on/lookup a component
> > > > directly.
> > >
> > > Keep in mind the purpose of the Selector/Manager relationship.
> >
> > I recall - one of the time I wished I had kept arguing ;)
>
> :) Maybe it is something we can address for the next version of
> Avalon framework.... In that case, I would like to drag Stefano
> into the midst of the discussion--he's pretty smart.
>
> I personally want to remove the necessity of string resolution,
> but I haven't been able to come up with something that is happy
> for all of us involved. Strings are the major bottleneck of
> Avalon right now. Esp. for something like Cocoon where we we can
> expect over 1000 requests per second in a heavy traffic site
> (that translates to 86,400,000 hits in a day) and components
> are resolved at runtime. That's a lot of string opperations!
>
> That's a lot of Generator.ROLE + "/fooo"!
String operations can usually be cached. I know zip about cocoon,
basically, but why is it not possible to have
static String Generator.FOO_ROLE = Generator.ROLE + "/fooo"!;
> But that is another subject entirely.
quite correct. I'll shut up.
> > > The components available for Generation, Transformation,
> > > or Serialization are many. Plus it is hard to determine
> > what should
> > > be the actual mapping to the specified component. For example:
> > >
> > > Generator.ROLE + "/file"
> > > Generator.ROLE + "/stream"
> > > Generator.ROLE + "/foo"
> > >
> > > Truth be told, the File and Stream options can both be used
> > to get the
> > > same results....
> >
> >
> > dont see relevance of above ?
>
> Maybe not, but their implementations overlap.
<snip>
>
> The fact that they overlap would mean that really there shouldn't be
> implementations bound to separate locations. There should be one
> location.
> They aren't distinct enough. It would be like blocking IO vs.
> non-blocking
> IO. One scales better than the other, but they essentially do the same
> thing.
Still don't see the relevance. This is an analysis problem, not?
> Here is something that I have been thinking about lately.
> How can we have our cake and eat it too? How can we have a fast
> performing component hash without the limitations of the String.
1 - don't use String (use int, long, char[])
2 - cache Strings (define Strings as early as possible, minimise
operations on String, cache operations on String)
the advantage of 1 is a cleaner (smaller) implementation. The advantage
of 2 is a more intuitive API.
> In high transaction environments, this is critical. My previous
> attempts
> at coming up with something that would work for everyone have not been
> up to par. I am still stuck on trying to come up with something. I
> think
> a query object is better than Strings.
For high performance, yes. For general use, an unneccessary level of
indirection or an extra method call as you use strings anyway.
How often do you need to server millions of requests a day where the
bottleneck is not somewhere else?
> Strings have the limitation of
> being
> expensive to match, and expensive to hash. Especially when most of the
> string is the same. As a result, we can solve the problem like this:
>
> /**
> * Avalon 5 interface, so I can reuse the component manager name.
> */
> public interface ComponentManager
> {
> /**
> * These methods create a Request object for the CM. It will
> * return <code>null</code> if the component does not exist.
> */
> Request createRequest( String role );
> Request createRequest( String role, Object hint );
>
> /**
> * No need for exceptions because the Request object originates
> * from the ComponentManager. The only issue that might come up
> * is a Request object from a different CM--in that case a
> * RuntimeException is accpetable.
> */
> Object lookup( Request role );
/**
* Keep current method, basically making the call to
* createRequest internal. Also means these changes can probably
* be done somewhere in a future avalon 4 release as no existing
* functionality is removed or changed.
* Note that the CM could still do some smart caching of the
* generated Request objects internally.
*/
Object lookup( String role ) throws RuntimeException;
>
> /**
> * Still can't be convinced that this isn't necessary as long as
> * we have pooled components.
> */
> void release(Object component );
> }
g'night,
- Leo
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
