rdf-connect / ldes-client

The TREE/LDES client to replicate and synchronize LDESs: the RDF Connect processor
https://rdf-connect.github.io/ldes-client/
6 stars 2 forks source link

Caching of json-ld context documents #32

Open pietercolpaert opened 2 months ago

pietercolpaert commented 2 months ago

In rdf-derefence you can pass a custom fetch function: https://www.npmjs.com/package/rdf-dereference#input-using-a-custom-fetch-function

I wonder if there’s a way to implement regular HTTP caching, but only for the JSON-LD context documents if they need to be fetched externally. In the LDES client it otherwise does not make sense to have HTTP caching that stores the full response, as it is never going to be used again.

MPvHarmelen commented 1 month ago

I also noticed the lack of http caching in the client and came here to write an issue, but it's already there! :partying_face:

It otherwise does not make sense to have HTTP caching that stores the full response, as it is never going to be used again.

When developing a client (in the sense of "something that uses whatever ldes-client spits out"), caching the full http responses is actually very useful: during development one frequently resends exactly the same requests, because some other part of the code changed.

Also because the spec mentions http caching explicitly (in the first note of section 2), I expected the ldes-client to respect the cache headers.

pietercolpaert commented 1 month ago

The ldes-client is going to respect caching headers on a second run if you pass a state file location though using -s. Does that fix your problem?

MPvHarmelen commented 4 weeks ago

I didn't release the client implements its own caching, thanks!

Later it turned out that the endpoint that I was developing against doesn't return cache-control headers, so I think that was the root cause... :facepalm: