Leo Sutic wrote:
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.
Leo, can you please hand wrap your paragraphs? My mail client doesn't do it for
responses. It makes it easier for writing the responses.
Ok, now with the actual problem at hand. The typesafe interface would be
handy, but I have
to wonder *how* to practically use it. The issue is that I want the same feel
for both C++
as well as Java if that is how you are working with it.
There is always the possibility of adding methods such as attach(Object),
getAttachment(),
getSignal(). The best one of course being the getSignal(). By attaching an
integer to the
signal type, you can use a switch/case construct which is arguably better.
I want to stay away from strings being the signal type, and if possible, the
class type
being the signal type.
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)
That approach may be good for C++ (although I have to find more info), but how
does it translate
to Java?
I think that will help me wrap my head around the issue you are referring to.
I don't think
we are on the same page at all.
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.
Oh, no doubt. That is what I hope to accomplish. He has the theorhetical know
how,
but we have practical API writing experience. While he is addressing
performance
and scalability we are addressing practical aspects of the system.
--
"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]>
