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 >
