Re: [seda] event notifier pattern clarification

[Trustin Lee <tr...@gmail.com>]

I'm working on this issue (DIRSEDA-12), and I think I found a better solution.

The problem here was 'bypassing encoder and decoder is impossible for
current event routing model', and it was solved by RoutingAdvice, but
it looked somewhat messy; we had to have three(!) control factors! So
I tried to make them to two:

1. EventFilter: event types are also handled here by EventTypeFilter
utility class.
2. Source Subscriber: the subscriber who fired the event.

This two factor elegantly solves all of our routing issues completely
because it makes us to control the routing by 'source subscriber'.
'Who' fired this event?  It is probaly most important information!

and, here is my suggesting API:

public interface EventRouter {
       SubscriberContext add(String name, Subscriber subscriber);
       void remove(String name);
}

public interface SubscriberContext {
       String getName();
       void subscribe(String eventSourceName, Filter eventFilter);
       void unsubscribe(String eventSourceName, Filter eventFilter);
       boolean publish(SessionEvent event);
       SubscriberMonitor getMonitor();
       void setMonitor(SubscriberMonitor monitor);
}

public interface Subscriber extends EventListener {
       void inform(SubscriberContext ctx, SessionEvent event);
}

public interface Filter {
       static Filter ALL = new Filter() {
               public boolean accept(SessionEvent event) {
                       return true;
               }
       };

       boolean accept(SessionEvent event);
}

And here is the usage:

EventRouter er = ...;
SubscriberContext ctx;

er.add("listener", tcpLIstenerManager);
ctx = er.add("input", inputListenerManager);
ctx.subscribe("listener", Filter.ALL);
...

public class MySubscriber implements Subscriber {

   public void inform(SubscriberContext ctx, SessionEvent event) {
       // do something with event
       ....
       ctx.publish(replyEvent);
   }
   ....
}

HDYT?

I'm already working on this, and you can see it in
'trustin_api_redesign' branch now although there are a lot of
compilation errors in the implementation part.

Cheers,
Trustin Lee