Permalink
Browse files

differentiate retracting hls and streaming

  • Loading branch information...
1 parent 83184cb commit d82dc9ffccb75917241cbe88b25c6d04152be2ea Phuong Dinh committed Mar 14, 2013
@@ -12,7 +12,7 @@ class MatterhornClient
include Rubyhorn::RestClient::Ingest
include Rubyhorn::RestClient::Workflow
include Rubyhorn::RestClient::Exceptions
- include Rubyhorn::RestClient::HLSDistribution
+ include Rubyhorn::RestClient::Distribution
# repository configuration (see #initialize)
attr_reader :config
@@ -1,16 +1,25 @@
module Rubyhorn::RestClient
- module HLSDistribution
+ module Distribution
- def delete_track( media_package, track )
+ def delete_track( workflow_id, track_id )
+ media_package = Rubyhorn.client.get_media_package(workflow_id)
args = {
:mediapackage => media_package,
- :elementId => track
+ :elementId => track_id
}
post("distribution/streaming/retract", args)
end
- # example usage of delete_track
+ def delete_hls_track( workflow_id, track_id )
@atomical

atomical Mar 14, 2013

Contributor

I originally used get_media_package() in delete_track() but here are a few reasons I chose not to include it when I committed and favored the consumer of the API finding the media package:

  1. In our use case we will be deleting many tracks. That means for every track we want to delete we need an additional call to Matterhorn.
  2. If delete_track fails the application consuming the API won't know if get_media_package() returned 500 or if delete_hls_track() returned 500.
  3. I think it's possible that this violates principles of REST. I don't know enough about REST to make this claim with any certainty.
  4. I think the advantages of conforming to the Matterhorn API outweigh simplicity.
@phuongdh

phuongdh Mar 14, 2013

Contributor

I see your points. It depends on how we see Rubyhorn. Is it just an interface for MH REST endpoints, or it is part of Avalon and does more than that?

  1. It's unfortunate but the culprit here is MH, for asking us to pass in the whole mediapackage and not just the id! Also it's somewhat unreasonable to ask Avalon to get the mediapackage XML (which it does not understand or use) just to call the delete_track function. This probably won't happen too much to cause a performance issue.
  2. This is something Rubyhorn knows and cares about. I don't think Avalon needs to.
  3. Technically I don't think it makes a difference if you do this from Rubyhorn or Derivative model, they're parts of the rails app.
  4. Same as 3.
@mbklein

mbklein Mar 14, 2013

Owner

Good questions. +1 to @phuongdh's answers

@cjcolvar

cjcolvar Mar 15, 2013

Owner

When I started rubyhorn, I was trying to model it after rubydora which is a simple wrapper around Fedora's REST endpoints. Following the pattern used by Hydra, this discussion points to either a separate module within rubyhorn or a separate gem which uses rubyhorn but abstracts it for Avalon. At this point I think the former would be the simpler path (post-R1 of course).

Also, I would hope that rubyhorn becomes useful enough to be picked up by others in the MH ecosystem. I also think that keeping rubyhorn close to the MH API might help expose annoyances that should lead to patches instead of hiding it with convenience code.

+ media_package = Rubyhorn.client.get_media_package(workflow_id)
+ args = {
+ :mediapackage => media_package,
+ :elementId => track_id
+ }
+
+ post("distribution/hls/retract", args)
+ end
# def delete_workflow_tracks(workflow_id)
# media_package = Rubyhorn.client.get_media_package(workflow_id)
# tracks = media_package.xpath('//track').map{|node| node.get_attribute('id')}
@@ -20,4 +29,4 @@ def delete_track( media_package, track )
# end
# end
end
-end
+end

0 comments on commit d82dc9f

Please sign in to comment.