[asterisk-dev] [Code Review] Enhancements to presence in Asterisk

[Matt Jordan]

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



/team/mmichelson/trunk-digiumphones/funcs/func_presencestate.c
<https://reviewboard.asterisk.org/r/1850/#comment10950>

    If db_entry is NULL, it'd be nice if we printed out something like "No custom presence states defined."



/team/mmichelson/trunk-digiumphones/funcs/func_presencestate.c
<https://reviewboard.asterisk.org/r/1850/#comment10951>

    This seems like a very odd size for a buffer.  Is there a reason for 1301?
    



/team/mmichelson/trunk-digiumphones/funcs/func_presencestate.c
<https://reviewboard.asterisk.org/r/1850/#comment10953>

    If we can't parse the value in the data base into a valid presence state, it returns -1.  Furthermore, if we run out of delimiters in the comma separated list of values that we expect to be in state_info, we return 0, and the subsequent buffers passed into parse_data retain their original values.
    
    In those cases, the various character pointers will be pointing to who knows what.  If parse_data fails or returns earlier then we expect, we need to gracefully handle that here.



/team/mmichelson/trunk-digiumphones/funcs/func_presencestate.c
<https://reviewboard.asterisk.org/r/1850/#comment10955>

    Theoretically, it looks like this can do more then just set the state value, but can also set a subtype, message, and options if the user passed in something like:
    
    presencestate change CustomPresence:mystate1 AWAY,doughnuts,more doughnuts,e
    
    Should that be documented here?  Should we let a user set those values?



/team/mmichelson/trunk-digiumphones/funcs/func_presencestate.c
<https://reviewboard.asterisk.org/r/1850/#comment10954>

    Its possible that subtype, message, and options are not going to be set by parse_data.  Is it okay if they retain their original 'junk' values, and that gets passed to ast_presence_state_changed_literal?  Should we at least ensure that they're NULL?



/team/mmichelson/trunk-digiumphones/funcs/func_presencestate.c
<https://reviewboard.asterisk.org/r/1850/#comment10956>

    If somehow an invalid value got stuck in the database, parse_data would fail.  Since a user can now put values into the database through the CLI, this may not be completely outside the realm of possibility.
    
    Do we want to emit a warning if parse_data fails?


- Matt


On April 5, 2012, 5:32 p.m., Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1850/
> -----------------------------------------------------------
> 
> (Updated April 5, 2012, 5:32 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> This changeset contains revisions to the presence system in Asterisk to make it more palatable for general release in Asterisk 11. While the system as it exists in the 1.8-digiumphones and 10-digiumphones works well, it was missing some functionality and was not implemented in the most optimal way in some cases. Below are a list of the changes made:
> 
> * func_presencestate has two CLI commands added. "presencestate list" lists the current states of all CustomPresence entities. "presencestate change" allows for CustomPresence entities' states to be updated. These two commands are modeled after similar ones in func_devstate.
> * func_presencestate now populates the event cache on startup to mirror what func_devstate does.
> * The functions that change presence state have been updated to behave more like the ast_devstate_changed family of functions. This includes two main changes.
>     - There are now two functions to use, either ast_presence_state_changed() or ast_presence_state_changed_literal(). The difference between these is that one takes a printf-style format string and the other takes a literal name.
>     - The state change functions now take the state (and subtype and message) as part of the function. This saves the trouble of having to look up the state from the presence state provider on every state change. In the case of CustomPresence, this means far fewer ASTDB reads.
> * A new manager action, "PresenceState", has been added. This will return the current presence state, subtype, and message for a given presence provider.
> 
> 
> Diffs
> -----
> 
>   /team/mmichelson/trunk-digiumphones/funcs/func_presencestate.c 361324 
>   /team/mmichelson/trunk-digiumphones/include/asterisk/presencestate.h 361324 
>   /team/mmichelson/trunk-digiumphones/main/manager.c 361324 
>   /team/mmichelson/trunk-digiumphones/main/presencestate.c 361324 
> 
> Diff: https://reviewboard.asterisk.org/r/1850/diff
> 
> 
> Testing
> -------
> 
> I have tested the CLI commands and Manager actions. They exercise the core updates, so I can verify they work as well. I will have an external test written within the coming days and will post it when I have completed it.
> 
> 
> Thanks,
> 
> Mark
> 
>

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