ExportRecordedData #86
Conversation
Co-authored-by: Yuri Oliveira <[email protected]>
Co-authored-by: Austin Hammer <[email protected]>
lib/recording/create_recordig_job.ex
Outdated
| recording_token: ~x"//trc:JobConfiguration/tt:RecordingToken/text()"so, | ||
| mode: ~x"//trc:JobConfiguration/tt:Mode/text()"so, | ||
| priority: ~x"//trc:JobConfiguration/tt:Priority/text()"so | ||
| ) |
There was a problem hiding this comment.
Shouldn't this be parsed / structified with the RecordingJob module?
There was a problem hiding this comment.
this is very specific for this case, the schema is also different. This information is available on other API calls, this is the only one that I was trying to do differently, but if you rather have a standard "austin model" approach, I chan revert to ths standard one
There was a problem hiding this comment.
The parsing looks exactly the same to me in the code (with the exception that the namespace for JobConfiguration is different), except you aren't pulling the source out here. But it's optional so the parsing should still work if it is present, and then you get a nice struct as the result
There was a problem hiding this comment.
Possibly the namespace difference would cause issues here, but if you could test it just so we know and add a note that the ONVIF api spec has a bug that would be nice
| @@ -0,0 +1,168 @@ | |||
| defmodule Onvif.Recording.Recordings do | |||
There was a problem hiding this comment.
| defmodule Onvif.Recording.Recordings do | |
| defmodule Onvif.Recording do |
Same as above, without the module stuttering
lib/recording/recording_jobs.ex
Outdated
| xmap( | ||
| doc, | ||
| job_token: ~x"./tt:JobToken/text()"so, | ||
| job_configuration: ~x"./tt:JobConfiguration"eo |> transform_by(&parse_job_configuration/1) |
There was a problem hiding this comment.
should tt:JobConfiguration be trc:JobConfiguration?
There was a problem hiding this comment.
nope, as you can see here https://github.com/hammeraj/onvif/blob/po/exportRecordedData/test/recording/fixture/get_recording_jobs_success.xml#L58 it is tt
There was a problem hiding this comment.
Interesting, I looked through the docs and it appears that the JobConfiguration in the Create response should also be in the tt namespace but there are inconsistencies with the Onvif documentation
|
This is quite large, and it seems like there are some easy demarcations between recordings and job recordings where you could have split it into a few PRs |
lib/recording/create_recording.ex
Outdated
| Onvif.Recording.request(device, args, __MODULE__) | ||
| end | ||
|
|
||
| def request_body(%{name: name, content: content, max_retention: max_retention}) do |
There was a problem hiding this comment.
This should accept recording configuration as input like we do here. So that we can set all the input attrs. Right now I see we are defaulting to "" for some attrs. With the current approach of map as input we need to start adding new keys if we want to support setting all the attrs from the spec.
Co-authored-by: Logeshwaran <[email protected]>
What and Why
Implementation of the functions required to get recorded data as a URI.
Verification Steps
mix test test/replay/mix test test/recording/Onvif.Recording.CreateRecordingOnvif.Recording.GetRecordingJobsOnvif.Recording.GetRecordingsOnvif.Recording.GetRecordingJobsOnvif.Replay.GetServiceCapabilitiesOnvif.Replay.GetReplayUriTested on