Peter Donald wrote: > On Fri, 1 Feb 2002 08:24, Berin Loritsch wrote: > >>Generally impressed with Matt Welsh's work, I began extracting the concepts >>for Cornerstone. The issue is that the Stage is a specialized Component >>in the system, and we need a clean mechanism to manage inter-block stage >>architectures. Enter SILK. SILK is my acronym for Staged Interblock >>Linking Kernel. (Hense the continued play on SEDA being the spanish word >>for SILK). >> > > Kool sounding name ;) > > >>The general concept is that a Stage consists of the Component itself >>(handles the logic of the stage), >> > > runaway! runaway! runaway! > > Can't we use delegation instead ? ;)
What are you talking about? A Stage is a Component in the SEDA architecture. > > >>a group of input Sinks and one or more >>output Sinks. The SilkServer allows a Container to get a SourceMap for any >>stage that needs to be connected outside the system. >> > > So sourcemap is the way that you set up routing between elements? So > basically sourcemap == routing map ? No. The SourceMap is to provide the Source/Sources that connect to this *particular* stage. 9 times out of 10, a Stage will have one Queue Source to send events to, however there are cases where you have a multiplexing stage that sends events to two or more pipelines. Case and point: Cache Stage that will create events to the main pipeline for the information that it has, but will create events to the cache subpipeline for information it does not have, so it can resolve the resources. > The stage itself implements the routing table and also allocates resources to > each route according to some schedule/load balancing factors? No, The manager implements the routing table and manages the resources to each route according to..... You get the picture. The SourceMap is strictly to get a handle to the queue that forwards events to the next stage. It does not provide any *global* information. The named queue concept is so that the Stage can get the particular queue it needs. In essence the concept is similar to Block resolution. > If so I don't think exposing sourcemap directly is a good thing. I have > attached the interface I use for my log server that shows how I set up > routing tables for it. Maybe that will explain it clearer than my words ;) It's not what you think. The event routing can be reconnected at any time. > > >>My connundrum is trying to come up with a way to cleanly tie an >>EventHandler to a Stage. Should the stage implement EventHandler, should >>the configuration file manage the class to be invoked, or should there be a >>getHandler() method? >> > > How about another interface "EventHandlerFactory" that is responsible for > creating event handlers or something ? That way any strategy could easily be > implemented by implementing a different EventHandlerFactory object. No. That is not it. A Stage in essence *is* an EventHandler. I would prefer for stages to remain ThreadSafe, the current design allows for this, and the "EventHandlerFactory" is too much overhead for not enough problem. My issue is reconciling the Block Concept to the Stage concept. All Stages have the same interface, which allows the processing to be done incrementally. Blocks have discrete interfaces, which represent specific units of work. ---------------------------------------------------- Sign Up for NetZero Platinum Today Only $9.95 per month! http://my.netzero.net/s/signup?r=platinum&refcd=PT97 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
