Re: [Asterisk-java-users] Advanced Event Filtering

[Aaron E. <aar...@gm...>]

On 8/2/07, Martin Smith <ma...@be...> wrote:
> > -----Original Message-----
> > From: ast...@li...
> > [mailto:ast...@li...] On
> > Behalf Of Aaron Evans
> > Sent: Thursday, August 02, 2007 10:16 AM
> > To: ast...@li...
> > Subject: [Asterisk-java-users] Advanced Event Filtering
>
> > Event though my event listener may only process these extension status
> > change events, discarding all others, the asterisk java API will still
> > be building a very large number of these event objects at a very quick
> > rate.
>
> This is true, and I think filtering isn't a bad idea. In fact, there has
> been talk of filtering the data even further up the pipe, in Asterisk
> itself.
>

Yeah, I wish there were more event filtering options within asterisk.

> > This brings me to my next point/request.  While I could provide my own
> > ManagerReaderImpl by overriding the factory method in
> > ManagerConnectionImpl, the buildEvent method is private. :(
> > This means I can't just extend and override the ManagerReaderImpl.  In
> > fact, if I make a copy of this implementation to my application's
> > source tree, there are a great deal of classes and interfaces that are
> > not visible in the org.asteriskjava.manager.internal package (the
> > Dispatcher interface for example).  I guess that is kind of the point
> > of the "internal" package since these aren't really supposed to be
> > part of the API for developers.
> >
> > At the very least, I would propose making some of the methods of the
> > ManagerReaderImpl and ManagerWriterImpl classes protected rather than
> > private.
>
> I think the important reason that these implementations are private is
> because there are assumptions that are made inside of each class that
> you won't necessarily obey if you extend one, in turn breaking your
> application. In closed source projects, you'd almost *have* to do this
> so that your users don't break the default implementation and then blame
> you (or worse, do something malicious with your product). In open source
> world, I can see how this seems less fruitful, as someone can and will
> copy your private implementation, as you're suggesting you will be
> forced to do.
>
> > In order to avoid creating these ManagerEvent objects, I'm thinking
> > I'll inject the filter check in the buildEvent method of the
> > ManagerReaderImpl class.
>
> An alternative approach would be to make filtering more flexible for all
> users, by explicitly defining filter objects in the API. These filter
> objects would be required to make decisions based on something like the
> Map<String, String> that ManagerReaderImpl uses.
>

Yes, that would be good.

> > However, in this case, I have no choice but to modify the source
> > rather than supplying my own implementation (short of copying a great
> > many classes to my applications source tree).
>
> At the risk of sounding too harsh -- copying classes means you'll have
> to actually deal with the implementation details of the class directly,
> whereas someone who is just extending an implementation is much more
> likely to step on the toes of the original implementation for the worse.
> I actually like that kind of design -- you can force the programmer to
> be fully involved in the internals and make their own mistakes or stay
> out of your working implementation.
>

Not harsh at all, I agree with you 100%.  Copying classes is the last
thing I want to do.

> I'd much prefer, however, in this case, an open public API for the
> filtering, and then allow a user/developer to simply provide an
> implementation for that.
>

Agreed, that is the better approach but I don't think I'll be able to
wait for these features and I'll have to hack something out myself for
the time being.  If what I come up with seems pretty good, I have no
problem contributing it back.  I'll be modifying the source directly
and then building the customized jar for my application.

> Martin Smith, Systems Developer
> ma...@be...
> Bureau of Economic and Business Research
> University of Florida
> (352) 392-0171 Ext. 221
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Asterisk-java-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/asterisk-java-users
>