[asterisk-dev] [Code Review] 2585: Sorcery Extended Fields and Opaque Data

[Joshua Colp]

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

(Updated June 15, 2013, 1:19 p.m.)


Review request for Asterisk Developers.


Repository: Asterisk


Description
-------

This change adds two new things:

1. Extended fields

Extended fields are fields specifically marked as extending an object. This means they are not held to the same type safety as normal fields and simply exist as a list that can be queried. The pro of this is that the object that is extended does *not* have to be modified when other modules need to attach data to it. The con of this is that type safety must be enforced at the time of consumption by the user of the extended field. A test is also provided which confirms functionality.

2. Opaque sorcery data

Previously sorcery data was placed directly in the structure definition for objects. This had the consequence of requiring any modules using the structures to be recompiled if the sorcery structure changed. The change attached adds a generic sorcery object allocation function which allocates enough room for an internal opaque structure. This has the benefits that modules do not need to be recompiled if internal details change and it also allows additional data to be attached to sorcery objects and properly deallocated when the object is destroyed.


Diffs (updated)
-----

  /trunk/include/asterisk/sorcery.h 391941 
  /trunk/main/sorcery.c 391941 
  /trunk/res/res_sip/config_auth.c 391941 
  /trunk/res/res_sip/config_domain_aliases.c 391941 
  /trunk/res/res_sip/config_transport.c 391941 
  /trunk/res/res_sip/location.c 391941 
  /trunk/res/res_sip/sip_configuration.c 391941 
  /trunk/tests/test_sorcery.c 391941 

Diff: https://reviewboard.asterisk.org/r/2585/diff/


Testing
-------

Ran unit tests, confirmed all happy. Used Gulp functionality and confirmed it is also happy.


Thanks,

Joshua Colp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130615/d61b545d/attachment.htm>