[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="4.154.0.63"
 subject="quvi thoughts. excited!"
 date="2013-08-22T18:22:51Z"
 content="""
Anarcat's quvi suggestion is interesting, because it seems to simplify the whole thing down to just `addurl`, which git-annex is already good at.

If quvi manages to find the url that can be used to download the actual video file, without needing to run a special downloader, then all you really need, it seems, is `git annex addurl --relaxed $(quvi youtube-url)` The --relaxed will make git-annex not care if the content or size of the url's content varies in the future. Since --relaxed skips the actual download, you'd want to follow that with `git annex get`, since we don't know how long these urls will last..

I suppose git-annex could, if quvi is available, make any attempt to download a web special remote url that
matches the `quvi --support` output run the url through quvi to get the real url and download that instead. The  difficulties with this approach:

* would need to read and parse `quvi --support` every time it gets an url from the web special remote? (I don't think I'd want to link with libquvi, although that would be possible, just because this is an edge thing.)
* what it an url that had been supported stopped being supported -- we'd not want to download the raw url in that case
* putting the quvi support here doesn't allow relaxed mode to be set when `addurl` adds the url.

Maybe it would be better to keep the support in `addurl`, and record the url generated by quvi. That url would probably be more likely to break in the future, but that kind of breakage is why `git annex untrust web` is wise..
Keeping the support in `addurl` would also let it use the title that quvi also returns to determine the filename it creates.
"""]]