git-annex/doc/todo/addurl_improvements.mdwn

When an external special remote tells git-annex a fuller URL for a given file, git-annex-addurl does not use that information:

    [2018-10-28 16:12:39.933464] git-annex-remote-dnanexus[1] <-- CLAIMURL dx://file-FJZjVx001pB2BQPVKY4zX8kk/
    [2018-10-28 16:12:39.933515] git-annex-remote-dnanexus[1] --> CLAIMURL-SUCCESS
    [2018-10-28 16:12:39.933568] git-annex-remote-dnanexus[1] <-- CHECKURL dx://file-FJZjVx001pB2BQPVKY4zX8kk/
    [2018-10-28 16:12:40.469292] git-annex-remote-dnanexus[1] --> CHECKURL-MULTI dx://file-FJZjVx001pB2BQPVKY4zX8kk/A4.assembly1-trinity.fasta 11086 A4.assembly1-trinity.fasta
    addurl dx://file-FJZjVx001pB2BQPVKY4zX8kk/ (from mydx) (to A4.assembly1_trinity.fasta) [2018-10-28 16:12:40.469503] read: git ["--version"]

It would be better if, in the above log, the URL key was based on dx://file-FJZjVx001pB2BQPVKY4zX8kk/A4.assembly1-trinity.fasta , which would preserve the .fasta extension in the key and therefore in the symlink target.

> [fixed|done]] --[[Joey]]

Also, it would be good if the external special remote could return an etag
for the URL, which would be a value guaranteed to change if the URL's
contents changes; and if git-annex would then compute the URL key based on
the combination of URL and etag.

> This might be a good idea if sufficiently elaborated on, but I am a one
> idea, one bug, one page kind of guy. I dislike reading over a long detailed
> discussion of something, like the problem above and my analysis of it,
> only to find a second, unrelated discussion of something else. 
> Suddenly the mental state is polluted with
> different distinct things, some fixed, other still open. The bug tracking
> system has then failed because it's not tracking state in any useful way. 
> Which is why I've closed this todo item with my fix of
> a single item from it. --[[Joey]]

It'd also be good if there was a option to automatically migrate URL keys
to the default backend whenever a file from a URL key is downloaded.  Also,
to record the checksummed key (e.g. MD5E) as metadata of the URL key (in a
field named e.g. alternateKeys), and if addurl --fast is later done on a
URL key for which a checksummed key is recorded in the metadata, to add the
checksummed key instead of the URL key .

> Again, mixing discussion of several things in one place is a good way to
> muddy the waters. I think this idea has several problems, but don't want
> to discuss them here. --[[Joey]]