Think of wording for drive.download() method

[RangerMauve]

It'd be nice to have an HTTP method which enables you to download a directory, to go along with CLEAR for clearing locally stored data for it.

I proposed DOWNLOAD but @DeltaF1 rightfully said it could be confused along side GET.

Any other suggestions or input would be appreciated.

cc @calm-rad

[calm-rad]

I'm in favor of these being integrated!

I think CLEAR and DOWNLOAD are appropriate, and I personally think the distinction between DOWNLOAD and GET makes sense, but here are some potential alternatives we could consider: LOAD STORE SAVE

As for functionality, I'm assuming it would download an entire directory or a file depending on the URL, correct?

I think it would also be useful to filter what kind of content should be downloaded with the Content-Type in the request header. But would it be deviating too far from expected behavior if we allowed arrays being passed to Content-Type if we want to permit multiple MIME-Types?

My last thought is on what the DOWNLOAD response body would return. Maybe something like {path: 'local/path/to/file', size: [Number_In_Bytes]}?

[RangerMauve]

I was thinking of going simple and give it the options from hyperdrive.download() to start. Putting in a filter could be cool, though. It might be good to enable whatever filter API to hyperdrive itself in that case. 🤔

[DeltaF1]

I like STORE. More options: KEEP FETCH (Bad naming since it sounds like the fetch() API)

Should users expect that GET requests also DOWNLOAD resources? I.e. is there a guarantee that something that has been GET'ed will be available offline until CLEAR'ed?

[RangerMauve]

IPFS uses Pin/Unpin

[RangerMauve]

GET requests always download a resource and it stays until they clear it.

This should probably change by adding an LRU. :P

[RangerMauve]

Sticking with DOWNLOAD and CLEAR for now