You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The RAAPI spec says that servers may unpack or pack assets based on request, that is the server may unpack a tarball fetched using FetchDirectory and vice versa. Perhaps we should implement this, although it may be more prudent to wait for clients to expect it.
I foresee many details causing headaches with this functionality:
How will this interact with Qualifiers?
Qualifiers are already difficult to wrap the head around, and this will complicate things even further. For example, one can imagine a client FetchBlob request on a directory containing a checksum.sri qualifier, intended to check that the packed directory matches a given checksum - this may be a cheap way to ensure a directory is exactly what was expected - and so this qualifier would be handled after the transformation. On the other hand, for the same reasons, calling FetchDirectory on a blob with this qualifier set, I'd expect the opposite - the qualifier to be applied beforehand.
This is just a single example, and I'm sure there will be an endless rabbit hole filled with more subtleties
Are we expected to populate both directory and blob?
It may be nicer to only fetch the source once and do this packing/unpacking at a single Fetch. However, in doing this we meet an issue that certain qualifiers may only be applied to blobs or directories exclusively. Also, it seems inefficient to do this even if clients don't expect it.
We will need to record whether the asset is a Directory or a Blob
In order to return the correct response we will need to make sure the cached value matches the request, otherwise we may be sending a blob rather than a directory which the client expects.
Implementing this alongside #3 may also be more difficult. I don't think this is urgent until a client expects this behaviour really.
The text was updated successfully, but these errors were encountered:
The RAAPI spec says that servers may unpack or pack assets based on request, that is the server may unpack a tarball fetched using
FetchDirectory
and vice versa. Perhaps we should implement this, although it may be more prudent to wait for clients to expect it.I foresee many details causing headaches with this functionality:
How will this interact with Qualifiers?
Qualifiers
are already difficult to wrap the head around, and this will complicate things even further. For example, one can imagine a clientFetchBlob
request on a directory containing achecksum.sri
qualifier, intended to check that the packed directory matches a given checksum - this may be a cheap way to ensure a directory is exactly what was expected - and so this qualifier would be handled after the transformation. On the other hand, for the same reasons, callingFetchDirectory
on a blob with this qualifier set, I'd expect the opposite - the qualifier to be applied beforehand.This is just a single example, and I'm sure there will be an endless rabbit hole filled with more subtleties
Are we expected to populate both directory and blob?
It may be nicer to only fetch the source once and do this packing/unpacking at a single
Fetch
. However, in doing this we meet an issue that certain qualifiers may only be applied to blobs or directories exclusively. Also, it seems inefficient to do this even if clients don't expect it.We will need to record whether the asset is a Directory or a Blob
In order to return the correct response we will need to make sure the cached value matches the request, otherwise we may be sending a blob rather than a directory which the client expects.
Implementing this alongside #3 may also be more difficult. I don't think this is urgent until a client expects this behaviour really.
The text was updated successfully, but these errors were encountered: