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 change in 498c278 makes the catalog display a file download button in the content tab only if the file content URL is http(s). I think it is overly restrictive.
As an alternative, I would propose that a download button should be reported for any URL that has a scheme (in Python terms, that would mean urlparse(url).scheme != "" instead of urlparse(url).scheme.startswith("http")). That would eliminate the situation where a url is treated as relative to the catalog location without excluding things like e.g. (s)ftp.
Premises:
It is ok if a url cannot generally be accessed (due to credentials, specific network, required handler).
It might be for some users (who have credentials, etc.).
Displaying such URL still communicates information (knowing it exists, what the netloc is).
Protocols like (s)ftp are, I suppose, less common but also reasonable to use for content urls.
While a browser may be unable to open them, other programs can be registered as handlers (alternatively copy&paste).
Being http(s) does not guarantee that its content can be accessed, and we can't know that from looking at the url alone (see first point)
This is not to suggest a quick change, but rather to understand better what is the desired behavior and role of the URL/download display in the content tab.
I agree the current state is a somewhat blunt "fix". I do think the UX is important though, and having a download button that always fails is bad UX. I would suggest more fit-for-purpose functionality, such as having a scheme for interpretation and having different renderings and UX accordingly.
The change in 498c278 makes the catalog display a file download button in the content tab only if the file content URL is http(s). I think it is overly restrictive.
As an alternative, I would propose that a download button should be reported for any URL that has a scheme (in Python terms, that would mean
urlparse(url).scheme != ""
instead ofurlparse(url).scheme.startswith("http")
). That would eliminate the situation where a url is treated as relative to the catalog location without excluding things like e.g. (s)ftp.Premises:
This is not to suggest a quick change, but rather to understand better what is the desired behavior and role of the URL/download display in the content tab.
Counterpoint by @jsheunis from sfb1451/metadata-catalog#50 (comment)
Previous discussions:
The text was updated successfully, but these errors were encountered: