05:12 <politas> !tell w1r3dh4ck3r You are unlikely to ever get a response within ten minutes. The number of team members just isn't high enough for that kind of IRC responsiveness. The 1.24.0 pre-release version of CKAN includes a new "consoleui" interface which includes a tool for importing mod downloads into the CKAN cache.

05:12 <Qboid> politas: I'll redirect this as soon as they are around.

05:24 <ckanbot> [CKAN] politas commented on issue #2258: Would it not make sense to just check whether a mod already appears as an expanded treenode and refuse to expand it (showing an "Already expanded" fake node as the only child)? That would prevent loops of three or more mods as well. https://git.io/vN2D4

06:41 <ckanbot> [CKAN] HebaruSan commented on issue #2258: This solution handles loops of three or more mods. It checks _all_ of the ancestor nodes.... https://git.io/vN293

15:29 <ckanbot> [CKAN] dbent commented on issue #2210: Is the only reason to have a `github_download` field so that the HTTP client knows to set the `Accept` header? In that case I'd rather just bump the spec version, dump that information in the `download` field, and just always set the `Accept` header to `application/zip; application/octet-stream`. https://git.io/vNaoa

15:32 <ckanbot> [CKAN] dbent commented on issue #2210: Actually, since we store the content type in the metadata as `download_content_type`, the `Accept` header should default to: `${download_content_type}; application/octet-stream`. https://git.io/vNaop

15:37 <ckanbot> [CKAN] dbent commented on issue #2210: Is the only reason to have a `github_download` field so that the HTTP client knows to set the `Accept` header? In that case I'd rather just bump the spec version, dump that information in the `download` field, and just always set the `Accept` header to `application/zip, application/octet-stream`. https://git.io/vNaoa

15:37 <ckanbot> [CKAN] dbent commented on issue #2210: Actually, since we store the content type in the metadata as `download_content_type`, the `Accept` header should default to: `${download_content_type}, application/octet-stream`. https://git.io/vNaop

15:39 <ckanbot> [CKAN] dbent commented on issue #2210: Actually, throw in some [quality values](https://developer.mozilla.org/en-US/docs/Glossary/Quality_values) to asset that we would prefer the specified content type over some arbitrary binary stream and we should have something that works for anything: `application/zip;q=1.0,application/octet-stream;q=0.9`. https://git.io/vNaKy

15:39 <ckanbot> [CKAN] dbent commented on issue #2210: Actually, throw in some [quality values](https://developer.mozilla.org/en-US/docs/Glossary/Quality_values) to assert that we would prefer the specified content type over some arbitrary binary stream and we should have something that works for anything: `application/zip;q=1.0,application/octet-stream;q=0.9`. https://git.io/vNaKy

15:39 <ckanbot> [CKAN] dbent commented on issue #2210: Actually, throw in some [quality values](https://developer.mozilla.org/en-US/docs/Glossary/Quality_values) to assert that we would prefer the specified content type over some arbitrary binary stream and we should have something that works for anything: `${download_content_type};q=1.0,application/octet-stream;q=0.9`. https://git.io/vNaKy

17:07 <ckanbot> [CKAN] HebaruSan commented on issue #2210: Essentially it's because older clients will fail to download the API URLs, and the metadata is shared between old and new clients. If we switch all the URLs over in CKAN-meta, then everyone who hasn't upgraded to the newest CKAN will get download errors for *all* GitHub URLs, *every time*. https://git.io/vNaQY

18:18 <ckanbot> [CKAN] HebaruSan commented on issue #2262: OK, maybe there's something weird with those relationships then. What's the full mod list? https://git.io/vNahN

18:48 <ckanbot> [CKAN] dbent commented on issue #2210: The way that I would roll it out would be as follows:... https://git.io/vNVfh

18:49 <ckanbot> [CKAN] dbent commented on issue #2210: The way that I would roll it out would be as follows:... https://git.io/vNVfh

19:08 <ckanbot> [CKAN] HebaruSan commented on issue #2210: Sounds like a good plan to me. We can probably add the Accept header in 1.24... https://git.io/vNVTE

19:14 <ckanbot> [CKAN] HebaruSan commented on issue #2210: Wait, if the spec version requirement prevents them from downloading, then what do steps 3-5 buy us as compared to just switching the URLs immediately? GitHub downloads break either way, but changing the URLs would actually fix something as well. https://git.io/vNVk4

19:25 <ckanbot> [CKAN] dbent commented on issue #2210: I suppose we don't need step 5 and can do 3-7 pretty much simultaneously. https://git.io/vNVIp

19:30 <ckanbot> [CKAN] HebaruSan commented on issue #2210: OK, sorry, I forgot some pieces of the puzzle since writing this up.... https://git.io/vNVL2

19:33 <ckanbot> [CKAN] dbent commented on issue #2210: Couldn't that be specially handled in the client by checking for the presence of a `api.github.com` host in the download URL, rather than having extra metadata? https://git.io/vNVLp

20:23 <ckanbot> [CKAN] HebaruSan commented on issue #2210: Hmm, so far so good:... https://git.io/vNVsM

20:25 <ckanbot> [CKAN] HebaruSan commented on issue #2210: Hmm, so far so good:... https://git.io/vNVsM

20:29 <ckanbot> [CKAN] HebaruSan commented on issue #2210: Yeah, that makes sense. In fact, we can have a `Dictionary<string, string>` to store a mapping from any download host to an auth token, in case other servers add this in the future.... https://git.io/vNVG4

20:37 <ckanbot> [CKAN] dbent commented on issue #2210: > Where would we store the tokens?... https://git.io/vNVZG

20:47 <ckanbot> [CKAN] HebaruSan commented on issue #2210: Regarding use of `download_content_type`, that's not going to work. It's set to `application/zip` for every download in the registry, but the GitHub API needs it to be `application/octet-stream`:... https://git.io/vNVnc

20:47 <ckanbot> [CKAN] HebaruSan commented on issue #2210: Regarding use of `download_content_type`, that's not going to work. It's set to `application/zip` for every download in the registry, but the GitHub API needs it to be `application/octet-stream`:... https://git.io/vNVnc

20:51 <ckanbot> [CKAN] dbent commented on issue #2210: `Accept` can take multiple comma-delimited values. Use `application/zip;q=1.0,application/octet-stream;q=0.9`, which tells the server "I prefer `application/zip` will also accept `application/octet-stream` if you can provide it".... https://git.io/vNVnp

20:52 <ckanbot> [CKAN] dbent commented on issue #2210: `Accept` can take multiple comma-delimited values. Use `application/zip;q=1.0,application/octet-stream;q=0.9`, which tells the server "I prefer `application/zip`, but will also accept `application/octet-stream` if you can provide it".... https://git.io/vNVnp

20:58 <ckanbot> [CKAN] HebaruSan commented on issue #2210: Yeah, I realized that after I posted and deleted that comment. It does indeed work even in a patched CKAN. https://git.io/vNVcy

23:27 <ckanbot> [CKAN] HebaruSan opened pull request #2263: Accept header and infrastructure for auth tokens (master...feature/auth-tokens) https://git.io/vNV6l