[asterisk-commits] oej: branch group/astridevcon2007 r65832 - /team/group/astridevcon2007/

[asterisk-commits at lists.digium.com]

Author: oej
Date: Thu May 24 09:07:15 2007
New Revision: 65832

URL: http://svn.digium.com/view/asterisk?view=rev&rev=65832
Log:
Add SNMP notes from Asterisk-dev.

Added:
    team/group/astridevcon2007/snmp-meeting.txt   (with props)

Added: team/group/astridevcon2007/snmp-meeting.txt
URL: http://svn.digium.com/view/asterisk/team/group/astridevcon2007/snmp-meeting.txt?view=auto&rev=65832
==============================================================================
--- team/group/astridevcon2007/snmp-meeting.txt (added)
+++ team/group/astridevcon2007/snmp-meeting.txt Thu May 24 09:07:15 2007
@@ -1,0 +1,40 @@
+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
+

Propchange: team/group/astridevcon2007/snmp-meeting.txt
------------------------------------------------------------------------------
    svn:eol-style = native

Propchange: team/group/astridevcon2007/snmp-meeting.txt
------------------------------------------------------------------------------
    svn:keywords = Author Date Id Revision

Propchange: team/group/astridevcon2007/snmp-meeting.txt
------------------------------------------------------------------------------
    svn:mime-type = text/plain