1 Commits (0774d9f9aa663b42d9a40a15d017c817c12e3a5f)

Author	SHA1	Message	Date
Kevin Harwell	363bafc29e	stasis_state: Add new stasis_state module ... This new module describes an API that can be thought of as a combination of stasis topic pools, and caching. Except, hopefully done in a more efficient and less memory "leaky" manner. The API defines methods, and data structures for managing, and tracking published message state through stasis. By adding a subscriber or publisher, consumers can more easily track the lifetime of the contained state. For instance, when no more publishers and/or subscribers have need of the topic, and associated state its data is removed from the managed container. * stasis_state_manager * The manager stores and well, manages state data. Each state is an association of a unique stasis topic, and the last known published stasis message on that topic. There is only ever one managed state object per topic. For each topic all messages are forwarded to an "all" topic also maintained by the manager. * stasis_state_subscriber * Topic and state can be created, or referenced within the manager by adding a stasis_state_subscriber. When adding a subscriber if no state currently exists new managed state is immediately created. If managed state already exists then a new subscriber is created referencing that state. The managed state is guaranteed to live throughout the subscriber's lifetime. State is only removed from the manager when no other entities require it. * stasis_state_publisher * Topic and state can be created, or referenced within the manager by also adding a stasis_state_publisher. When adding a publisher if no state currently exists new managed state is created. If managed state already exists then a new publisher is created referencing that state. The managed state is guaranteed to live throughout the publisher's lifetime. State is only removed from the manager when no other entities require it. * stasis_state_observer * Some modules may wish to watch for, and react to managed state events. By registering a state observer, and implementing handlers for the desired callbacks those modules can do so. * other * Callbacks also exist that allow consumers to iterate over all, or some of the managed state. ASTERISK-28442 Change-Id: I7a4a06685a96e511da9f5bd23f9601642d7bd8e5	6 years ago