Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MediaObject#show setting up instance variables unnecessarily slowing down page #5477

Closed
1 task
cjcolvar opened this issue Nov 21, 2023 · 4 comments
Closed
1 task
Assignees

Comments

@cjcolvar
Copy link
Member

cjcolvar commented Nov 21, 2023

Description

The MediaObject#show action setup a number of instance variables for the player which may not be necessary now that ramp is rendering pretty much all of the item show page. The work to setup these variables are also duplicative given ramp requests the IIIF manifest. I'm guessing that section information is being fetched from solr and stream tokens setup which aren't used at all. @media_object is probably still needed for certain authorization checks but we can make sure that SpeedyAF isn't loading any children relations that aren't needed. (See note in #5476)

Done Looks Like

  • MediaObject#show action is cleaned up to include only what is needed to render ramp and the show page.
@cjcolvar
Copy link
Member Author

cjcolvar commented Dec 1, 2023

I did a quick investigation on this and found that it will be a bit harder than I had anticipated. It also revealed some functionality gaps that we will probably need to address before release.

Functionality that needs to be added to ramp:

  • Ability to pass starting canvas into ramp (also need to make sure share links/embed code/etc. match starting canvas)
  • Ability to pass starting time (t=) into ramp

The player page needs to setup media object and master file objects on page load in order to populate the share panel. It seems like there are two options for handling this: put all of the needed information into the IIIF manifest or have the page dynamically request /stream. (/stream is an endpoint that provides share links, embeds, etc.) I'd favor the former if it makes sense.

Possible changes to avoid needing /stream endpoint which provides share panel information:

  • Put homepage property on canvas for share url
  • Use homepage properties for "Share this resource"
  • Is there a place in the IIIF manifest to include information needed for the embed code?

Other places where media object/master file information is needed:

  • When initializing Avalon ramp component lots of information is passed in including: master file count, has_structuralMetadata, transcripts, supplemental files, etc.
  • _item_view.html.erb needs current stream for oembed links in header
  • Some other partials need ordered_master_file_ids, @masterFiles, and @media_object.master_files

@joncameron
Copy link
Contributor

joncameron commented Dec 6, 2023

Generated Issues

Ability to pass starting canvas into ramp (also need to make sure share links/embed code/etc. match starting canvas): #5493
Ability to pass starting time (t=) into ramp: #5508
Condense Solr calls: #5509
Adding Share information to the IIIF manifest: #5502

@joncameron
Copy link
Contributor

joncameron commented Dec 6, 2023

Looking again at Solr calls for the item show page might be the only quick win at the moment.
Cleaning up /stream would be a nice to have but probably isn't going to help page generation speeds.
Making calls to /stream purely dynamic won't help much for page generation load times.

@cjcolvar
Copy link
Member Author

Wrote up new issue for the rest of the work mentioned in my comment above: #5543

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants