[asterisk-dev] Notes from SNMP breakout session

[Marc Blanchet]

I was the one to suggest a new API as a shim layer between  
"customers" such as:
+ CLI (may be not all commands, but the first targets would be the  
show ones),
+ SNMP
+ manager
+ others (dial plan applications?)
therefore, the data is consistent between all views of the same data.
I did this in a previous life and this is really the way to go.

Given that the API is not intrusive, but added, the customers such as  
CLI can use whenever needed. no sync is needed.

this API work and its first customer (SNMP) should be included in  
1.6, whatever status of how "customers" of that API are using it or not.

my 2 canadian cents

Marc.

Le 07-05-23 à 17:14, Jeff Gehlbach a écrit :

> Hi!
>
> Some good discussion came from the SNMP breakout session this  
> afternoon
> at astridevcon.  The conversation moved quickly from "what to do with
> SNMP / res_snmp" to the realization that a new layer / API is needed
> within Asterisk to provide internal stats.  The reasoning behind this
> thinking is that res_snmp is really the third component that needs to
> get at lots of internal data.  The CLI and the manager are the others.
>
> A new internal stats data API would become the place to go when you  
> need
> information on the system's behavior or performance.  It would be
> somewhat like the event infrastructure that has come up in several
> discussions this week at astridevcon, only it's for take-out  
> whereas the
> event stuff is for delivery.
>
> The CLI, AMI, and res_snmp would all become customers of this API.
> I think that the above comprise the full list of existing components
> that should be customers.  Do any others come to mind?
>
> Once the API customers are identified, the next step is to identify  
> all
> the data that must be exposed to serve these customers and to define a
> generic way to represent the data internally.  Finally, the customer
> components can be moved one piece at a time to the new API.
>
> Concerns that came up in the breakout are the following:
>
> * Making the internal data representation generic enough for any
>   customer component to consume it -- what existing C-language  
> projects
>   exist from which we could draw inspiration (aka steal code) in this
>   realm?
> * Getting the API done and debugged in time for 1.6 will be "fun"
> * Concurrency - the rest of Asterisk will be changing around and under
>   those working on this project.  Doing the work in a branch will  
> help,
>   but awareness of this project in the developer community will be
>   critical.  Hence this post :)
> * Distributedness - same as with the new event stuff, the stats  
> data API
>   needs to be designed with an eye towards working (or at least being
>   easily adapted) in a distributed installation.
>
> Comments earnestly solicited!
> -jeff
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev

-----
IPv6 book: Migrating to IPv6, Wiley, 2006, http://www.ipv6book.ca