[asterisk-dev] [Code Review] 2693: ARI: Implement /recordings/stored API's
David Lee
reviewboard at asterisk.org
Fri Jul 26 12:07:59 CDT 2013
> On July 25, 2013, 10:29 a.m., opticron wrote:
> > /trunk/res/stasis_recording/stored.c, line 21
> > <https://reviewboard.asterisk.org/r/2693/diff/1/?file=42421#file42421line21>
> >
> > This appears to be a media indexer of sorts. Was there any reason not to use the one we already have?
It didn't seem appropriate. Specifically, the need for explicitly
updating the index as the recordings/registered formats changes does
not play well with recordings.
There were a few other features that didn't fit well, either.
Description processing does not apply. Neither does variants.
Multi-format barely applies.
Actually...
If I modify the indexer to better handle the recordings directory
(basically, to build the index on-demand instead of eagerly), it would
probably work. I'll give that a go.
- David
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2693/#review9212
-----------------------------------------------------------
On July 23, 2013, 11:11 a.m., David Lee wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2693/
> -----------------------------------------------------------
>
> (Updated July 23, 2013, 11:11 a.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 395154
> /trunk/res/Makefile 395154
> /trunk/res/res_stasis_http_recordings.c 395154
> /trunk/res/res_stasis_playback.c 395154
> /trunk/res/res_stasis_recording.c 395154
> /trunk/res/stasis_http/ari_model_validators.h 395154
> /trunk/res/stasis_http/ari_model_validators.c 395154
> /trunk/res/stasis_http/resource_recordings.h 395154
> /trunk/res/stasis_http/resource_recordings.c 395154
> /trunk/res/stasis_recording/stored.c PRE-CREATION
> /trunk/rest-api/api-docs/recordings.json 395154
>
> 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/20130726/c3df3182/attachment.htm>
More information about the asterisk-dev
mailing list