fauno (04cfb31b) at 13 Mar 20:43
v0.4.1
fauno (7a815c93) at 11 Mar 17:44
v0.4.0rc3
fauno (16b94b3c) at 11 Mar 17:44
v0.4.0
fauno (16b94b3c) at 11 Mar 17:44
v0.4.0
We'll possibly need to parse application/ld+json responses as deferentiable objects, so we can traverse them without extra steps. Right now we need to instantiate the first one at least.
Also the clients cache may be shared across all instances, indexed by public key URL, so we don't have many clients for the same instances.
fauno (a7e1f3bc) at 16 Feb 14:32
v0.4.0rc2
fauno (45a2c29c) at 16 Feb 14:32
v0.4.0rc1
fauno (a79dd63a) at 16 Feb 14:32
v0.4.0rc0
fauno (a7e1f3bc) at 16 Feb 14:31
v0.4.0rc2
https://github.com/drbrain/net-http-persistent
Dereferencing should be faster if we're using persistent connections
I was thinking to look for HTTParty support for timeouts but found this instead: https://github.com/Shopify/semian
With it, as soon as a remote instance fails and during the run of a build, we can fail gracefully by not waiting for the same timeout to happen everytime, and a failing instance doesn't slow down everything.
Just realized that at least in our cases, the id
attribute leads to an HTML page and the server isn't configured to redirect to the JSON-LD activity if it finds an accept: application/ld+json
header on the request. So we'll need to parse the HTML5, find the <meta>
tag linking to the activity and refetch it.
I wonder if we could do this while streaming the page contents instead of downloading and parsing everything.
Also could we try it as a redirect on HTTParty?
I'm not sure who's using it on the wild