Problem/Motivation

We download csig files, hash files, quasi-patch files and much more. Provide some layer of caching for these artifacts.

Proposed resolution

I'm not sure that we want to store these things in any database. They are files. Guzzle offers some layer of HTTP caching, but that would require additional dependencies and we're trying to limit those. I'm not sure the best path forward. Hopefully someone has suggestions.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Comments

heddn created an issue. See original summary.

pwolanin’s picture

pwolanin CreditAttribution: pwolanin as a volunteer and at SciShield commented

I'm not sure I understand this - drupal.org already uses a CDN, right?

Or is this about a cache local to the Drupal site?

heddn’s picture

heddn
Primary language English
Location Nicaragua
CreditAttribution: heddn as a volunteer and at MTech, LLC, Tag1 Consulting for Drupal Association, European Commission and European Union Institutions, Agencies and Bodies commented

Local to the drupal site. Downloading 2MB every 3 hours (for Drupal core) + more for any contrib modules seems like a heavy load on the site-side of things. Especially when these assets won't change from weeks and months at a time.

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers at Acquia commented
Assigned: Unassigned » tedbow
Issue tags: +Needs documentation updates
Related issues: +#3318306: Define the Package Manager API (package_manager.api.php is outdated)

@tedbow: Is this still relevant? I see zero mentions of csig in the codebase. Is this referring to update XML?

In any case, I think artifacts downloaded by composer are already cached locally. But … that should be documented in package_manager.api.php, which is already known for being outdated (see #3318306: Define the Package Manager API (package_manager.api.php is outdated)).

tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
CreditAttribution: tedbow at Acquia commented
Version: 8.x-1.x-dev » 7.x-1.x-dev
Assigned: tedbow » Unassigned

@Wim Leers this is for the 8.x-1.x version of the module which does not support composer. 8.x-1.x is unsupported so I am going to change to 7.x-1.x incase the maintainers of that branch still want to look into that.