[asterisk-dev] [Code Review] 3136: cli: pjsip show endpoint <endpoint> shows allow/disallow codecs the same - OPTION 1

[Matt Jordan]

> On Feb. 6, 2014, 9:52 a.m., Joshua Colp wrote:
> > While this works I'm not happy with pushing this down to such a low level. What if in the future I want to filter something else?
> > 
> > What I'd really like to see is something on top which allows you to arbitrarily filter anything. If something similar came up in the future then we'd have an immediate easy solution with no core changes and it would also allow the information to still exist for cases where you do want to get it.
> 
> Scott Griepentrog wrote:
>     The other option would be to add another parameter to the ast_sorcery_object_field_register() which would indicate a "hidden" option.  I can write that up as a separate review and see which one is preferred.  Which is now up for review: https://reviewboard.asterisk.org/r/3193/
>
> 
> Joshua Colp wrote:
>     I disagree that that is the only other option. You don't have to consume the information provided from sorcery as-is, and you don't have to push filtering down to that level. Something that sits between sorcery and the consumer can easily do the filtering based on information the consumer provides.
> 
> Joshua Colp wrote:
>     To go a step further: Whether an object field should be hidden is not a property of the object field itself, it is a constraint within the consumer.

I'm in 100% agreement with Josh here. I don't think this or option 2 are the right approach.

A framework should provide information to consumers. It is up to the consumer to decide how that information is displayed.

What do we mean by consumer?

Today, that is the CLI and AMI. But it doesn't have to be.

I could just as easily have a module that extracts information about SIP endpoints via a sorcery object and transmits that data over a JSON websocket (why, I don't know, but think of the integration!) Since it is not displaying information to an end user, it might want to see the disallow field. It might not: but the answer is, I don't know what it wants to send. If this becomes part of the framework, then it precludes this module from ever existing. You can't go back and simply 'undo' not showing the option - you've now broken the CLI/AMI. Your only option is to undo it *and* modify the CLI/AMI, and now that module has become intrusive.

I'd rather keep this sorcery agnostic of how things use it. Whenever possible, let the consumers decide what and how to show data. A filter is not a bad thing; it is appropriate for a consumer to filter out what it doesn't want to show.


- Matt


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3136/#review10786
-----------------------------------------------------------


On Feb. 6, 2014, 11:40 a.m., Scott Griepentrog wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3136/
> -----------------------------------------------------------
> 
> (Updated Feb. 6, 2014, 11:40 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23092
>     https://issues.asterisk.org/jira/browse/ASTERISK-23092
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> WAS:
> 
> Insert a ! prefix in the display of endpoint disallow value.  Result is:
> 
>  disallow                      : !(ulaw|alaw)
> 
> NOW:
> 
> Remove the disallow option from generated lists, while still accepting it from a configuration file.
> 
> 
> Diffs
> -----
> 
>   /branches/12/res/res_pjsip/pjsip_configuration.c 407196 
>   /branches/12/main/sorcery.c 407196 
>   /branches/12/main/config_options.c 407196 
>   /branches/12/include/asterisk/config_options.h 407196 
> 
> Diff: https://reviewboard.asterisk.org/r/3136/diff/
> 
> 
> Testing
> -------
> 
> Ran command and checked output.
> 
> 
> Thanks,
> 
> Scott Griepentrog
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140206/7d15bff0/attachment.html>