I cannot return anything.
Well, that just means you need a callback...take a look at
interface Decoder
{
Message decode( byte[] buf );
}class DecoderInputSubscriber extends AbstractSubscriber
implements InputSubscriber
{
private Decoder m_decoder; public DecoderInputSubscriber( Decoder decoder )
{
m_decoder = decoder;
} public void inform( InputEvent a_event )
{
EventAssert.assertOfType( a_event, InputEvent.class );
InputEvent event = ( InputEvent ) a_event;
byte[] l_buf = event.getBuffer() ;
Object result = m_decoder.decode( l_buf );
ResultSubscriber subscriber = a_event.getResultSubscriber();
subscriber.inform( new ResultEvent( result, a_event ) );
}
}a good place to learn about stuff like this is transaction frameworks and session management libraries. When things are sent over wires, an identifier of some kind is associated with the InputEvent, and it is sent back with the result, instead of the entire event. If we stay within the JVM, we can just pass around the object reference.
The headaches (like Niclas pointed out) come from everything becoming asynchronous. With these kinds of callbacks, you'll need to start thinking real hard about the management of the message flow. You often don't want the Decoder client to block indefinately waiting for the ResultEvent to arrive. It's not an unsolvable problem; the Mach kernel is one famous example :D
I guess I still need to think about this idea a bit more. Still scratching the old noggin.
:D
-- cheers,
- Leo Simons
----------------------------------------------------------------------- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles & Opinions -- http://articles.leosimons.com/ ----------------------------------------------------------------------- "We started off trying to set up a small anarchist community, but people wouldn't obey the rules." -- Alan Bennett
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
