Skip to content
Snippets Groups Projects
  • Mark Michelson's avatar
    f55abe9c
    Decouple subscription handling from NOTIFY/PUBLISH body generation. · f55abe9c
    Mark Michelson authored
    When the PJSIP pubsub framework was created, subscription handlers were required
    to state what event they handled along with what body types they knew how to
    generate. While this serves well when implementing a base RFC, it has problems
    when trying to extend the body to support non-standard or proprietary body
    elements. The code also was NOTIFY-specific, meaning that when the time comes
    that we start writing code to send out PUBLISH requests with MWI or presence
    bodies, we would likely find ourselves duplicating code that had previously been
    written.
    
    This changeset introduces the concept of body generators and body supplements. A
    body generator is responsible for allocating a native structure for a given body
    type, providing the primary body content, converting the native structure to a
    string, and deallocating resources. A body supplement takes the primary body
    content (the native structure, not a string) generated by the body generator and
    adds nonstandard elements to the body. With these elements living in their own
    module, it becomes easy to extend our support for body types and to re-use
    resources when sending a PUBLISH request.
    
    Body generators and body supplements register themselves with the pubsub core,
    similar to how subscription and publish handlers had done. Now, subscription
    handlers do not need to know what type of body content they generate, but they
    still need to inform the pubsub core about what the default body type for a
    given event package is. The pubsub core keeps track of what body generators and
    body supplements have been registered. When a SUBSCRIBE arrives, the pubsub core
    will check that there is a subscription handler for the event in the SUBSCRIBE,
    then it will check that there is a body generator that can provide the content
    specified in the Accept header(s).
    
    Because of the nature of body generators and supplements, it means
    res_pjsip_exten_state and res_pjsip_mwi have been completely gutted. They no
    longer worry about body types, instead calling
    ast_sip_pubsub_generate_body_content() when they need to generate a NOTIFY body.
    
    Review: https://reviewboard.asterisk.org/r/3150
    ........
    
    Merged revisions 407016 from http://svn.asterisk.org/svn/asterisk/branches/12
    
    
    git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407030 65c4cc65-6c06-0410-ace0-fbb531ad65f3
    f55abe9c
    History
    Decouple subscription handling from NOTIFY/PUBLISH body generation.
    Mark Michelson authored
    When the PJSIP pubsub framework was created, subscription handlers were required
    to state what event they handled along with what body types they knew how to
    generate. While this serves well when implementing a base RFC, it has problems
    when trying to extend the body to support non-standard or proprietary body
    elements. The code also was NOTIFY-specific, meaning that when the time comes
    that we start writing code to send out PUBLISH requests with MWI or presence
    bodies, we would likely find ourselves duplicating code that had previously been
    written.
    
    This changeset introduces the concept of body generators and body supplements. A
    body generator is responsible for allocating a native structure for a given body
    type, providing the primary body content, converting the native structure to a
    string, and deallocating resources. A body supplement takes the primary body
    content (the native structure, not a string) generated by the body generator and
    adds nonstandard elements to the body. With these elements living in their own
    module, it becomes easy to extend our support for body types and to re-use
    resources when sending a PUBLISH request.
    
    Body generators and body supplements register themselves with the pubsub core,
    similar to how subscription and publish handlers had done. Now, subscription
    handlers do not need to know what type of body content they generate, but they
    still need to inform the pubsub core about what the default body type for a
    given event package is. The pubsub core keeps track of what body generators and
    body supplements have been registered. When a SUBSCRIBE arrives, the pubsub core
    will check that there is a subscription handler for the event in the SUBSCRIBE,
    then it will check that there is a body generator that can provide the content
    specified in the Accept header(s).
    
    Because of the nature of body generators and supplements, it means
    res_pjsip_exten_state and res_pjsip_mwi have been completely gutted. They no
    longer worry about body types, instead calling
    ast_sip_pubsub_generate_body_content() when they need to generate a NOTIFY body.
    
    Review: https://reviewboard.asterisk.org/r/3150
    ........
    
    Merged revisions 407016 from http://svn.asterisk.org/svn/asterisk/branches/12
    
    
    git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407030 65c4cc65-6c06-0410-ace0-fbb531ad65f3