What I was saying is that instead of extending the AbstractSubscriber class, I think the same flexibility can be achieved by extending the Filter class. The problem with pushing filtering into the subscriber is that you have no flexibility on using the same EventSubscriber to handle two different types of events.
Kishore, do you have any thoughts about this? Kanak ---------------------------------------- > Date: Sun, 23 Mar 2014 14:07:28 -0700 > Subject: Re: Helix API: Update for 03/23/2014 > From: [email protected] > To: [email protected] > > Hi Kanak, > > See comments inline > > On Sun, Mar 23, 2014 at 1:42 PM, Kanak Biscuitwala <[email protected]> > wrote: >> >> Hi Sandeep, >> >> (1) Isn't the Filter class already generic enough to provide this level of >> pluggability? > [Sandeep] I did not change the Filter class, I simply made the > EventService take a Subscriber for subscription registration and > pushed the parameters to be interface methods on the Subscriber. That > way if we need subscribers to pass in more parameters during > subscription we enhance it through the Subscriber interface, we always > ask that they extend the AbstractSubscriber provided to shield > themselves from the Subscriber interface changes. > >> >> (2) Sure, I agree with this. >> >> (3) Looks fine. Do we need a ConnectionId and a SubscriberId? > > [Sandeep] The SubscriberId is tied to events subscribers so they can > unregister their subscriptions simply by passing in the id and not > having to hold on to the Filter and all the objects in the subscribe > call as it was before my changes. The connection id is used to track > connections for HelixConnection, we can do away with it if we think we > don't ConnectionId. > >> >> Kanak >> ---------------------------------------- >>> Date: Sun, 23 Mar 2014 13:15:36 -0700 >>> Subject: Helix API: Update for 03/23/2014 >>> From: [email protected] >>> To: [email protected] >>> >>> Here are the changes >>> >>> (1) I reworked the EventManager API to make it a bit more coarse >>> grained to allow easier extensions. >>> >>> (2) I have removed the id packages from model.id, statemachine.id into >>> a singular package api.id since some of the other packages had one or >>> two classes and did not make sense to have too many packages just for >>> ids. >>> >>> (3) I added a api.client package with interfaces for >>> HelixConnectionFactory, HelixConnection, HelixSession as place holders >>> which will get fleshed out after discussions. I did not move the >>> HelixConnection from core> org.apache.helix as it has too many >>> dependencies. I think we need to rework it into API piece by piece >>> before we remove it. >>> >>> Please take a look. I will step away for a bit but will check back in soon. >>> >>> Thanks, >>> >>> Sandeep >>
