On 18.07.18 06:40, Julian Reschke wrote:
On 2018-07-18 04:09, Matt Ryan wrote:
I’ve changed the code to use URIs instead of URLs.
Regarding the HTTP-specific naming: The latest iteration of the API
requires some HTTP-specific elements that need to be able to be set on
download URIs. More specifically, these are elements that the
implementation directs a service provider to set headers to certain
values on responses to requests for the signed download URIs. These
are things like being able to set the response Content-Type or
Content-Disposition header for example. (This is discussed further in
OAK-7637.)
As a result I do think it is evolving to be a bit HTTP-specific.
Are there specific concerns with the naming as it is?
I would say that these are not *necessarily* HTTP-specific, and thus we
should try to define them in a generic way.
I agree when we look at file name and content type, these are also
present in JCR when you have a nt:file/nt:resource node structure, but
we probably also want to add a content disposition type to the download
options. How would you define this in a generic way?
Regards
Marcel
