Hi Anshul,

On Thu, Dec 25, 2014 at 11:11:06AM +0530, Anshul Garg wrote:

Dear Mr Dmitry ,

Thanks a lot for the clarification.

I was in assumption that one handler can support both ->filter() and
->event[s]()
Callback.So that's why i have prepared the patch to first do the
filter then pass
the events.

Can you please tell me why current implementation doesn't expect handler can
have both callbacks?

Because it was something I saw no need for: filter already has all the
events so it can process them. If you really want to process events
again once all filters have run, you can register additional handler.

I think input core should be generic to allow any type of handlers which can
support both filter and events callbacks.

Please help to answer above query as my patch is based on this pre-assumption
that one handler can support both callbacks .

If we really need to have support of such handlers in input core then
only my patch
is good.

I think I would need a user for this feature before changing the code to
allow it.

Thanks.

-- 
Dmitry