[asterisk-dev] [Code Review] 2693: ARI: Implement /recordings/stored API's

[David Lee]

> On Aug. 5, 2013, 11:10 a.m., Matt Jordan wrote:
> > /trunk/res/stasis_recording/stored.c, line 138
> > <https://reviewboard.asterisk.org/r/2693/diff/2/?file=43044#file43044line138>
> >
> >     I'm assuming that the intent of providing an initializer list here is to set the members of entry to 0.
> >     
> >     It's a little vague to me whether or not having an empty initializer list counts as having at least one initializer, and thus whether or not each struct member past the first initializer will be set to 0 or not becomes very murky.
> >     
> >     If this were " entry = { 0, };" it'd be much clearer what the intent was.

It's standard behavior that elements not listed in the initializer list
get initialized with zero's, so it stands to reason that if nothing's in
the initializer list, then everything is zero initialized.

As it turns out[1], though, an empty initializer list isn't standard C.
There's actually no really reason to initializer the struct here
anyways, so I just removed it to avoid controversy.


- David


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


On July 29, 2013, 5:21 p.m., David Lee wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2693/
> -----------------------------------------------------------
> 
> (Updated July 29, 2013, 5:21 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-21582
>     https://issues.asterisk.org/jira/browse/ASTERISK-21582
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This patch implements the ARI API's for stored recordings. While the
> original task only specified deleting a recording, it was simple
> enough to implement the GET for all recordings, and for an individual
> recording.
> 
> The recording playback operation was modified to use the same code for
> accessing the recording as the REST API, so that they will behave
> consistently.
> 
> There were several problems with the api-docs that were also fixed,
> bringing the ARI spec in line with the implementation. There were some
> 'wishful thinking' fields on the stored recording model (duration and
> timestamp) that were removed, because I ended up not implementing a
> metadata file to go along with the recording to store such information.
> 
> The GET /recordings/live operation was removed, since it's not really
> that useful to get a list of all recordings that are currently going
> on in the system. (At least, if we did that, we'd probably want to
> also list all of the current playbacks. Which seems weird.)
> 
> 
> Diffs
> -----
> 
>   /trunk/include/asterisk/stasis_app_recording.h 395718 
>   /trunk/res/Makefile 395718 
>   /trunk/res/ari/ari_model_validators.h 395718 
>   /trunk/res/ari/ari_model_validators.c 395718 
>   /trunk/res/ari/resource_recordings.h 395718 
>   /trunk/res/ari/resource_recordings.c 395718 
>   /trunk/res/res_ari_recordings.c 395718 
>   /trunk/res/res_stasis_playback.c 395718 
>   /trunk/res/res_stasis_recording.c 395718 
>   /trunk/res/stasis_recording/stored.c PRE-CREATION 
>   /trunk/rest-api/api-docs/recordings.json 395718 
> 
> Diff: https://reviewboard.asterisk.org/r/2693/diff/
> 
> 
> Testing
> -------
> 
> Used Swagger-UI to poke around the API. Verified that you couldn't
> delete anything outside the recording's directory.
> 
> 
> Thanks,
> 
> David Lee
> 
>

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