On Sat, 2 Feb 2002 15:49, Berin Loritsch wrote:
> After re-examining Matt Welsh's SandStorm server kernel, I have come to
> the conclusion that Stages conceptually are the EventHandlers. The
> confusion came from studying the interfaces and reading his thesis.
> While the concepts relate, the names are somewhat different. In
> SandStorm (his SEDA kernel), the Stage is merely an object to manage
> stage/queue relationships. The EventHandler is where the real work is
> done. In fact, after examining the Haboob HTTP server code, there is
> no class that extends Stage or directly implements Stage. There is
> only the classes the implement EventHandler.
yep ;)
> I am open to suggestions of how to reconcile the Stage and Block
> pieces. I see how some of it will work together quite nicely,
> but I also see how some of it will overlap.
Heres how I would do it and how I have done similar things in the past.
* EventRouter: Create a block that allows you to set up the route through
SILK stages programatically (like attached interface).
* EventHandlerRegistry: create a block that acts as a registry for factories
of different eventHandlers. (used by RouteConfigurator)
* RouteConfigurator: Create a block that reads in a user specified config
file and uses that to set up EventRouter block.
Create blocks or vanilla classes that implement the eventhandler factories
and somehow have these placed in registry.
Then implement the application specific glue code and event handlers. It may
look like a lot of uneeded abstraction but it has served me relatively well
so far. Especially the abstraction between EventRouter and EventConfigurator.
> It provides alot of functionality, but I wonder if providing the ability
> to separate portions of the event driven architecture accross block
> boundaries is a flawed concept. My original thinking in this line was
> to keep the ability to separate a server into ProtocolHandling sections
> and Store management sections (i.e. SMTP, POP3, IMAP, mail queue, etc.).
> However, that could also be happening at the Stage level.
Applicaiton specific call. The SMTP/POP3 protocols (and all other lock-step
or request-response protocols) generally have a lot of idle time interspiced
with fixed commands. In these architectures the events would roughly
corespond to the appearance of a command. Other things like HTTP have
different layers (ie decode headers, accumulate content, send to logic,
generate response headers, generate response content).
So in some cases it could be useful to expose EventHandlers as blocks while
at other times it may be best if EventHandlers were just normal components
that were created by a "manager" Block. Im not sure if that helps ;)
--
Cheers,
Pete
"You know what a dumbshit the 'average man' on the street is? Well, by
definition, half of them are even dumber than that!"
J.R. "Bob" Dobbs
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
