> [Harmeet]
> One time timer task rather than repeated timer tasks is the same thing as
> Watchdog timeout. It is property of implementation.
> Schedulers can work like one-time alarm clocks.
If I recall correctly, the Scheduler interface isn't designed to support
truly lightweight special purpose timeouts. It is designed to act as a
manager -- as a mux. And that imposes overhead, unless you just ignore the
interface contract.
> If you have an object that monitors timeout on lots of events, it would
have
> the same property and load. It may be called a watchdog or a scheduler.
A lightweight watchdog doesn't monitor lots of events.
> lightweight-effiicient etc. are properties of implementation. The
scheduler
> abstraction cannot enforce or avoid any of these.
An interface is a contract specifying abstract behavior, and it does have an
impact.
scheduler.addTrigger( this.toString(), trigger, this );
scheduler.resetTrigger(this.toString());
Unless you're willing to discard the contract and say that THIS Scheduler
implementation has a different semantic interpretation then you have both a
string lookup issue and an obligation to handle multiple triggers. I'd
rather have a well-defined interface for a watchdog object than depend upon
an unusual semantic interpretation of the Scheduler interface that makes my
client code dependent upon a particular implementation of Scheduler.
> [Harmeet]
> A Config object can take care of this. Handlers don't need to
> expose themselves to lifecycle. What you are describing is configuration
per
> handler and as you pointed out that is not needed.
Are you proposing that servers be (semi-)generic Avalon Frameworks objects,
and that most of the work be done in a handler that is not integrated with
the Avalon lifecycle?
> [Harmeet]
> Listener-dispactch(handler) is the pattern followed in current code. It is
> more flexible than server class hierarchy. The missing piece is confusing
> and repeated configuration of the handler not a problem with the pattern
> iteself. Most other servers try to separate the listeners from dispatch
> workers/handlers.
I agree that a server -- dispatch --> worker model is good. I disagree that
the server is 100% generic, although there should be considerable common
code. More below.
> > Adding a "params" object would either require re-validation
> Params/Config need not require revalidation and if they do there will be
the
> overhead that you are avoiding by server class hierarchy.
I'm not sure, but I think that the two of you are missing each other's
points on this one. Here is my take:
Any common "params" object, post-initialization, would be configured with
validated information specific to the needs of a given service. It would be
"common" to the handlers, but not to other services. SOMEONE is responsible
for instantiating and populating the service specific configuration
information from the environment's configuration information. That someone
is the SERVER, not the handler, to my way of thinking. Therefore, if for no
other reason, there is a notion of service specific server behavior.
Minimal, perhaps, but existent.
> Cache the config. Precalculation for handlers, isn't that the only gain in
> having a server class hierarchy. Maybe that idea can be abstracted and
used
> with current model.
Yes, caching a config object could be abstracted, but instantiating and
populating it is still service specific. And unless the config object has a
(slow) generic access mechanism (like a property table), it is going to be a
service specific type. So, yes, you could have a config bean, but it would
still be a service specific type.
If you disagree, please outline the alternative.
> I am saying listeners are generic. Handlers/Workers are specific. A mix
> of two makes service and servers.
Did I miss someone adding a protocol specific listener? Where? And are you
saying that there is nothing specific to a service other than the handler?
> But a socket listener associated with SMTP handler makes an SMTP Service.
Who knows about preparing service specific configuration information, such
as maximum message size, online filtering, or authentication options?
Surely not the handler, which doesn't get invoked until there is a
conversation ready to happen.
> An incremental and better system would be Socket Listener with Config
Object
> and Handler makes a Service.
> A Bad State would be a server class hierarchy that couples Listener,
Config
> and Handler.
If there is nothing specific about being a server other than configuration
information, then we might get away with a single generic server, and
Class-based instantiation of service specific objects:
<service type="Foo" ...>
...
</service>
config = Class.forName(getType() + "Config");
handler = Class.forName(getType() + "Handler");
But I don't know if we've established that configuration information is the
only service specific behavior. And it seems to me that Avalon pretty much
does the preceeding, except that "Config" is the block / service.
-------------------------------
> > So if you wanted to have two different SSL socket types,
> > one for use by the NNTP server and another for use by the
> > SMTP server (a very common configuration), then you would
> > have to run two separate servers. Very bad.
> It is pretty standard. Take a look at tomcat. They do the same thing.
Huh? Behind the "Connectors" the code is the same, and in their case, the
wire level protocols are different. In this case, the protocol is NNTP,
SMTP, IMAP, POP3, ..., regardless of whether the transport layer is secure
or not. Oughtn't that be primarily a function of the listener, not the
handler?
> The observer-observable is a clean and standard pattern way. It allows an
> observer to monitor and decide on timeout reset.
Yah, but what is the observer, and what/how is it observing? That is a
valid question. Are you observing in the domain of a byte stream, or are
you observing in the domain of a semantic protocol? That appears to be the
specific nature of this dispute.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
