This is another known issue that I'm opening just so we have a place to discuss it. Right now the Ooyala module is not capable of updating any video properties after the video has initially be uploaded. Ideally we'd want the video updated on the Ooyala servers when the title or description was changed on the Drupal side.

Taxonomy presents special challenges in that Ooyala wouldn't handle things like the renaming of Taxonomy terms very nicely, so perhaps we should maintain a special set of tags in Ooyala (such as "drupal/...") to keep them separate from other tags. This would make it easier to synchronize Drupal terms while not affecting tags set up by the users in Backlot.

CommentFileSizeAuthor
#10 ooyala_taxonomy.patch49 KBquicksketch
#9 ooyala_sync_terms-632232-950760.patch23.07 KBsirkitree
#7 ooyala_sync_terms-632232.patch42.99 KBsirkitree
#4 ooyala_sync_terms.patch42.6 KBquicksketch

Comments

heronog’s picture

heronog commented

yes, I think that's the best way to do it. the inner tree structure well, I'm not so sure, but I think we could go with TID's, making the tags in backlot look like

"drupal/vid/tid/child-tid/2nd-child-tid/3rd-child-tid/..." so we don't lose the term id in case of term renaming.

I'm already working on a better API class so we can use it as a layer instead of putting all this logic inside the module

quicksketch’s picture

quicksketch
he/him
commented
Version: » 6.x-1.x-dev

I'll be working on this functionality shortly, however for our purposes it's actually more important that the tags have some kind of value on the Ooyala side of things, so sending over the TID is not so appealing for us. For our use-case, access to Backlot is extremely limited (since it has very little access control) and most editors upload through Drupal. We want the tags in Ooyala to make sense, since we'll likely assemble dynamic channels based on these tags ("See more videos about 'Term name'"). Maintaining Ooyala tags is not so important since very few users will be using Backlot.

That said, Ooyala stores tags in Key => Value pairs. So what I'm thinking is that we simply store the Drupal VID as the key but the value is actually the taxonomy term name. In the event that a taxonomy term is renamed, we can query Ooyala and update it across the board, but my guess is this won't happen regularly.

quicksketch’s picture

quicksketch
he/him
commented

I've recently been in discussion with some folks over at Ooyala and they're strongly recommending that we use Ooyala Labels instead of Ooyala Tags for storing taxonomy information. Labels naturally support hierarchy like Drupal Vocabularies and make for a more natural fit. When using Labels, the Vocabulary name would be the top-level Label, with terms being everything underneath them. Drupal Tags would be a single Label in Ooyala, with each Tag being a Label underneath the main "Tags" label.

Ooyala was even so kind as to change their API to expose Label IDs, meaning we can make a direct correlation between Drupal term IDs and Ooyala Labels. I haven't yet tried out the new API but I'll report here as I make progress.

quicksketch’s picture

quicksketch
he/him
commented
Status: Active » Needs work
StatusFileSize
new ooyala_sync_terms.patch42.6 KB

Here's the current patch with this functionality so far.

sirkitree’s picture

sirkitree commented

Here is a preliminary review of this patch. I've not setup an instance using this taxonomy syncing feature in order to test it out yet, but I gave this review in hope of helping push it along a little. The main reason being that I need the ooyala_api_video_query() function for my own feature that I'm working on in #947310: Bulk import for Backlot videos into Drupal
---

+++ includes/ooyala.pages.inc	29 Sep 2010 17:40:17 -0000
@@ -115,7 +105,109 @@
+    '#access' => module_exists('taxonomy'),

you have an access check here for the field, but if this fails, we're still doing some taxonomy specific things. Maybe the whole things should be surrounded by module_exists('taxonomy')?

+++ includes/ooyala.pages.inc	29 Sep 2010 17:40:17 -0000
@@ -115,7 +105,109 @@
+  $form = system_settings_form($form);
+  $form['#submit'][] = 'ooyala_settings_form_submit';

again here. This submit function (as it's currently written) will execute even if we do not have the taxonomy module enabled. we probably shouldn't add the extra submit handler if taxonomy module is not enabled.

+++ ooyala.install	29 Sep 2010 17:40:18 -0000
@@ -37,3 +84,51 @@
+function ooyala_update_1() {

This should be function ooyala_update_6001() I think.

+++ ooyala.module	29 Sep 2010 17:40:19 -0000
@@ -495,6 +597,209 @@
+  // TODO: Ooyala APIs currently do not provide a way to delete labels.

With these TODOs that deal with the Ooyala API not having certain features yet: where do we get some sort of status or keep up to date with what they are implementing?

+++ includes/ooyala.pages.inc	29 Sep 2010 17:40:17 -0000
@@ -84,16 +84,6 @@
-  $form['ooyala_reporting_level'] = array(
-    '#type' => 'radios',
-    '#title' => t('Reporting level'),
-    '#options' => array(
-      '1' => t('Verbose - display errors and status messages'),
-      '0' => t('Quiet - log errors to watchdog (recommended for production sites)'),
-    ),
-    '#default_value' => variable_get('ooyala_reporting_level', 1),
-  );

Can you help us understand why you've removed this? I assume you think that watchdog is sufficient

Powered by Dreditor.

sirkitree’s picture

sirkitree commented

I've put in a bunch of bug fixes and features from oejthebrave so this patch doesn't apply cleanly anymore.


patching file includes/ooyala.pages.inc
Reversed (or previously applied) patch detected!  Assume -R? [n] y
Hunk #5 succeeded at 253 with fuzz 1 (offset -1 lines).
The next patch would create the file includes/ooyala.taxonomy.inc,
which already exists!  Assume -R? [n] y
patching file includes/ooyala.taxonomy.inc
patching file ooyala.install
Reversed (or previously applied) patch detected!  Assume -R? [n] y
Hunk #3 succeeded at 88 with fuzz 2 (offset 51 lines).
patching file ooyala.module
Reversed (or previously applied) patch detected!  Assume -R? [n] y
Hunk #2 succeeded at 179 (offset 10 lines).
Hunk #3 FAILED at 192.
Hunk #4 succeeded at 286 (offset 86 lines).
Hunk #5 succeeded at 308 (offset 86 lines).
Hunk #6 succeeded at 315 (offset 86 lines).
Hunk #7 succeeded at 467 (offset 113 lines).
Hunk #8 succeeded at 597 (offset 114 lines).
Hunk #9 succeeded at 609 (offset 114 lines).
Hunk #10 succeeded at 626 (offset 114 lines).
Hunk #11 succeeded at 634 (offset 114 lines).
Hunk #12 succeeded at 642 (offset 114 lines).
Hunk #13 succeeded at 678 (offset 114 lines).
Hunk #14 succeeded at 690 (offset 114 lines).
Hunk #15 succeeded at 766 with fuzz 1 (offset 120 lines).
Hunk #16 succeeded at 1106 (offset 175 lines).
1 out of 16 hunks FAILED -- saving rejects to file ooyala.module.rej

I'll see if I can re-roll it.

sirkitree’s picture

sirkitree commented
StatusFileSize
new ooyala_sync_terms-632232.patch42.99 KB

Here's an attempt at a re-roll. Looks like it applies fairly well to HEAD.

patching file includes/ooyala.pages.inc
patching file includes/ooyala.taxonomy.inc
patching file ooyala.install
patching file ooyala.module
Hunk #16 succeeded at 1469 (offset 1 line).
sirkitree’s picture

sirkitree commented

Due to the complexity of this patch, and the fact that some of the api function quicksketch has created would be really useful to some of the other features planned for this module, I'm going to split this patch up a bit and extract the different api calls he's created and track that in another issue: #950760: New API function wrappers

The remaining patch will be *just* the synchronization portion of the patch. This will allow us to work with just the sync portion here, and then #947310: Bulk import for Backlot videos into Drupal will be able to benefit from the new api functions.

sirkitree’s picture

sirkitree commented
StatusFileSize
new ooyala_sync_terms-632232-950760.patch23.07 KB

Here is the revised patch that depends on the patch in #950760: New API function wrappers being applied or committed first.

quicksketch’s picture

quicksketch
he/him
commented
Title: Syncronize Taxonomy/Title/Description on Update » Syncronize Taxonomy with Ooyala Labels
Status: Needs work » Fixed
StatusFileSize
new ooyala_taxonomy.patch49 KB

I've committed this initial round which gets Taxonomy synchronization working. It does have a large caveat that it does *not* send current node taxonomy information to Ooyala when it is first enabled. I've been thinking that we need a universal "sync everything" command now that we have multiple things to worry about: labels, title, description, thumbnail, length, status, etc. But I want to commit this one first and then worry about that problem next.

This patch addresses the following:
- Sends taxonomy trees to Ooyala when enabled.
- Immediately renames/deletes/adds labels to Ooyala when changing Drupal Taxonomy terms.
- Renames/deletes/adds terms to Drupal when changing labels in Ooyala Backlot.
- Associates labels with videos when assigning Taxonomy terms to nodes.
- Pulls Ooyala labels from Backlot when doing the Bulk import.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.