[asterisk-dev] CLI verbosity on -rx

[critch]

On Thu, 2007-10-04 at 18:30 -0500, Russell Bryant wrote:
> Atis Lezdins wrote:
> > Guys, could you please take a look at http://bugs.digium.com/view.php?id=10847
> > 
> > The problem is that i expect `asterisk -rx "show queues"` to return only 
> > result of "show queues", as it would be in CLI with verbosity/debug 0. 
> > However, sometimes i get full CLI output for quite long period of time. Qwell 
> > insists that this is intended behaviour, but i don't agree. 
> > 
> > Is there any significant problem when executing remote command with separate 
> > verbosity than main thread? 
> 
> So, here is the issue.
> 
> The main instance of Asterisk calls ast_register_verbose() and provides a
> callback function called something like network_verboser().  This function
> provides all of the common CLI output to remotely connected consoles.  This
> output includes any log output, or verbose output.
> 
> The problem is that there is no way for the main Asterisk process to know the
> difference between a regular remote console (simply -r) versus one that is only
> connecting to execute a single command and exit (-rx).
> 
> The fix must make it such that the main Asterisk process can treat these two
> types of remote consoles differently.  I can think of 2 ways to do it.
> 
> 1) Create a 2nd unix socket.  Have connections to one for -r, and the other for
> -rx.  I think this is going to be the easiest way to fix it, and thus is my
> preferred method.
> 
> 2) Have the remove console send over some magic text when it first connects to
> indicate that it is a -rx console and should be treated as such.
> 
> Then, once the main process can treat them differently, it can properly _only_
> send the output of the desired CLI command to -rx consoles.

Maybe it is me, but this seems really odd. Seems that the presentation
is too tightly coupled with generation. I'm sure this suggestion won't
be the least disruptive option, but wouldn't a better solution be to
have all messages tagged in some way such that at presentation time you
filter it? 

Since you wouldn't want to send remotely more information than needed.
Maybe one could make a layer between presentation(socket to remote) and
the portions of the code generating the messages. Then when you connect
to the main asterisk instance, you auth and then start subscribing to
the messages you are interested in. 

Where this could get very interesting is if once you have the ability to
"subscribe" to certain types of information, maybe putting in mechanisms
to subscribe to information upon triggers. For instance a subscription
to all messages regarding a specific channel when a channel variable is
set, or a caller-id was seen. This would let you weed out all the other
debug messages that you aren't interested in. Imagine the time savings
on a busy system.

I could see similar interesting uses for "subscription" on triggers for
log files as well.

Just some thoughts,
-- 
critch <critch at basesys.com>