hypothesis / hypothesis/product-backlog

allow media fragments

Open
#436 2 comments 0 reactions 0 assignees View on GitHub
Dominant language
No language data
Stars
122
Forks
7
PR merge metrics
No merged PRs in 30d

Description

One approach to AV annotation using Hypothesis, https://blog.jonudell.net/2018/01/06/annotating-web-audio/, relies on H page notes that refer to web resources that define AV segments of interest.

A weakness of the approach is that H swallows fragment identifiers, so syntax like `{url}.mp3#t=23,47` only makes it into the system as `{url}.mp3`. I think it's only possible to annotate a separate resource -- which may be query-string-parameterized in a similar way -- that embeds an AV player.

To support media fragments, I think we'd only need to alter the filter here -- https://github.com/hypothesis/client/blob/master/src/annotator/guest.coffee#L33 -- to allow https://www.w3.org/TR/media-frags/#media-fragment-syntax.

And then capture the fragment sent from the client here:

https://github.com/hypothesis/h/blob/master/h/util/uri.py#L159

I've tried this, it seems to work. I am wondering:

- Are we open to a small PR for this?

- If so, what should the media fragment filter look like? It seems that the most basic `#t={params}` pattern (https://www.w3.org/TR/media-frags/#naming-time) is most widely supported in major browsers. And that would be simple to do. Would it be sufficient for starters?

- Are there gotchas associated with introducing urls like `{url}.mp3#t=23,47` into the Hypothesis ecosystem?

One thing that won't be an issue here, I think, is aliasing, because there's no HTML in the loop between `{url}.mp3|mp4` and the media player.

The inverse is maybe more interesting: expanding the set. It would be nice for adjacent segments to be more discoverable.

(Somewhat related: https://github.com/hypothesis/client/pull/646)

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reviewing the filter in src/annotator/guest.coffee and URI handling at h/util/uri.py#L159, then read the linked media-fragments specification and related client pull request. Determine how time fragments such as #t=23,47 should be accepted and preserved across the client and server; done means the behavior is implemented consistently and tested.

Written by the indexing model from the issue text.

Assessment

Tech stack
coffeescript, python
Domain
backend, web-dev
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.