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

[Martin S. <ma...@be...>]

> -----Original Message-----
> From: ast...@li...=20
> [mailto:ast...@li...] On=20
> 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.
=20
> 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.

> 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.

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.

Martin Smith, Systems Developer
ma...@be...
Bureau of Economic and Business Research
University of Florida
(352) 392-0171 Ext. 221=20