> Hmm.  What about Events like QueueClosed, or other control events 
> that go through the same queue?

Berin,

the problem is that I want a typesafe interface to the queue. If a queue 
accepts events of type A, B and C, then that should be made explicit via the 
Sink interface from that queue. I do not mind having to cast when removing an 
item from the queue, but when I have to cast something, I want to be sure the 
cast is correct without too much trouble.

Looking at Haboob, the event handlers are like:

if (element instanceof A) {
    ...
} else if (element instanceof B) {
    ...
} else if (element instanceof C) {
    ...
}

Which is a regression to the old procedural style programming paradigm where 
structures are passed around to idempotent functions. Just replace function 
with stage and structure with queue element.

> Not every queue will be passing references to Sockets or File 
> Handles.  They will be passing control
> events as well.  I don't think this is one place where templates 
> while a cool feature won't help
> the Queue implementation--esp. with respects to the type of events.

True. But if a typecheck and a cast is necessary, then the last one to see the 
"true" type of the object should ideally be the same one casting it back. 
(http://rampages.onramp.net/~huston/dp/type_restorer.html)

> See my replacement for this. [Sink interface] It is soo much better.

No objection. 
 
> I mean the guy that wrote SEDA not only has a Ph.D., but it doesn't seem to 
> be of the 
> variety where it is Piled Higher and Deeper (assuming you start with B.S.).

I have no doubts about Matt's ability to architect systems. Besides Ph.D and 
being funded by DARPA (an organization I hold in very high regard), he came up 
with SEDA and I didn't, and that has to count for something.

> I think we should learn from the lessons that Matt Welsh put 
> forth, as they are tested and not purely theorhetical.

True, but I believe that you can improve on his design. He has shown what works 
with Haboob, and his papers list what does not work. Now, if we stay away from 
what does not work I see no reason why we should not do our very best to 
improve on it.

/LS


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to