Peter Donald wrote: > On Tue, 17 Sep 2002 00:10, Berin Loritsch wrote: > > > + per-application > > > > Unless the component is in the root container, that should be > > "per-container". > > Kool - I was thinking of having a "per-partition"but I could not find any > examples of it in practice. For sub sitemaps, does Cocoon reuse parents > "ThreadSafe" components or recreate its' own?
It uses the Parent ComponentManager pattern set forth in Framework. A ComponentManager will check its parent if it cannot resolve the component. Now, I have screwed with the ComponentSelector patterns a bit in that they also delegate back to the parent. It was the only way to have sub sitemaps reuse selector hint mappings. > > > + per-thread > > > + per-access > > > > > > And I would also like to add "per-request" or "per-transaction" to model > > > the concept of "Component Transactions" that we have discussed in the > > > past (also to cover things like is represented in the proposal directory > > > of framework CVS. > > > > Right. Could you clarify the difference between "per-access" and > > "per-request"? > > per-access means that everytime you do a lookup() you get a new instance. > Where per-request means anyytime you do a lookup in same "Component > Transaction" you get the same component. Ok. So "per-transaction" would be better terminology. The problem with the transaction access layer is that it is an application specific concept. Not all applications have a concept of a transaction. If we consider "per-transaction" we would also have to consider "per-session". I can think of an "InboxManager" component that would maintain the current state of a users Inbox--with one instance per session.... Maybe that is something that needs to be thought out better. Do we want to represent application access points to be valid Avalon concepts> If so, how do we represent this in code with a generic enough implementation? What is more important is how do we determine when each of those scopes are finished? Unless we pass in some artifact like a Transaction/Context object, we will have no way of knowing in a framework level way when we have reached the boundaries of application specific access points. > > > Essentially what I am asking is, does it seem reasonable to break down > > > the lifestyle stuff this way? If so is shared a good aspect to > > > concentrate on? > > > > It remains to be seen how we expect to have it work. What problems does > > it solve? > > Two things. It means we can "assemble" lifestyle out of more primitive tags. > This will make it sooo much easier to extend this in the future. And yes - I > have a very practical reason in mind. :) I'm curious now. I guess I have to review all the M$ docs on attribute driven programming? > I have been inspired by some comments by Igor over in Phoenix land. Now I > think ALL of our containers are too primitive, too hard and too inflexible. > In a year they will all be considered obsolete, archaic remains. > > Those ideas I was trying to figure out in containerkit (and previously in > atlantis/camelot) are all WRONG WRONG WRONG. I have seen a very very very > nice future and it is when everything is written using interceptors. They do provide a starting point. The fact that they are "rigid" makes it easier for people to grasp what they do. I want to be careful that we don't go too far down a path that will cause us issues in maintenance and evangelism later. When I have a light bulb go off, I will probably support you 100%. We also have to consider what are we going to do right now. > That way you want to extend/change the container then it is simple as 1-2-3, > A-B-C. For example if you wanted to write an lifestyle that said "I pool > between times 3-5 each day and recreate all other times" that would be near > impossible with all the current containers. With this new architecture all > you need do is create a new interceptor, update the container config and > bang! you are done. > > Interceptors are the future. For my initial thoughts on them see You are looking at Interceptors to replace the experimental Extensions? > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12405 I'll take a look at your link in detail. > However my brain has mutated again. Now I have three sets of interceptor > chains per container. Access chain, Release Chain and Invoke chain. And > chains are allowed to invoke sub-chains. > > MetaData + Tools + Interceptors are what will bring Avalon from being "nice, > but an effort to get started" to "nice, when do we start". :) > > In the SEDA arena, there will be the concept of "stateless" and > > "per-thread". The "stateless" stage would use a thread-pool to manage > > load and provide concurrency. To make certain issues easier to deal > > with, the "per-thread" stage would have a unique instance, and a > > unique Source. Events would be split in a load balanced manner, and > > sent to the proper instance of the component. There wouldn't be any > > reason for "per-access" models in a SEDA environment. > > right - but as I said. Break these concepts down into their atomic parts and > things start becoming soo much nicer. Aye, and there's the rub. (to quote Hamlet's soliloquy). What is course grained enought to be easy to use, yet fine grained enough to be powerfully flexible. -- "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
