Implement Webdav#1390
Conversation
|
New Issues (3)Checkmarx found the following issues in this Pull Request
Fixed Issues (3)Great job! The following issues were fixed in this Pull Request
Communicate with Checkmarx by submitting a PR comment with @Checkmarx followed by one of the supported commands. Learn about the supported commands here. |
|
|
||
| app.include_router(get_zarr_router_v2(), prefix="/zarr/v2") | ||
| app.include_router(get_zarr_router_v3(), prefix="/zarr/v3") | ||
| app.include_router(get_webdav_router(), prefix="/api/webdav") |
There was a problem hiding this comment.
should this be /api/v1 to match the rest of the endpoints?
There was a problem hiding this comment.
I debated this. I can go either way, but my reasoning for omitting the the /api/v1 is that the WebDAV API is very well established. I don't think we'd make any modifications to the API itself other than possibly adding to it. Anything where we had to make a changes would be more of a bug fix than a functionality change.
There are a host of related "extra" specs in the webdav world that we don't support, and I'm not sure we would ever want to. For example, there's a spec for using webdav to change access controls on a resource. Even if we did decide to support one of them in the future, I think they would have to parts:
- Additional HTTP methods to support
- Additions to the XML documents that are part of the payload of some requests
| }, | ||
| "read:webhooks": {"description": "Read webhooks and delivery history."}, | ||
| "write:webhooks": {"description": "Register and delete webhooks."}, | ||
| "webdav:read": {"description": "Read data and metadata via WebDAV."}, |
There was a problem hiding this comment.
Should the order be reversed? E.g. read:webdav.
There was a problem hiding this comment.
Yes it should. However, @danielballan and I talked about this, and I think the way we'll go is to delete webdav-specific scopes and just use the read:data and read:metadata
2 participants
Checklist
WebDAV is a protocal for access folders over HTTP requests. Several methods and status codes were added to HTTP for WebDAV.
MacOs, Linux and Windows all have native support for mapping WebDAV servers from their explorers. (For Linux, I tested Nautilus, but I'm pretty sure the Konquerer can as well.) This makes a WebDAV endpoint a pretty useful way for people to access the data in WebDAV servers. This PR is intended to make it easier for users to use tiled in their day to day workflows.
Tiled does not by default present data as files. To make easy for users to interact with their data on the desktop, this endpoint presents nodes for the underlying file. So, for example, if you expnd an array node, the server will present the underlying component files as children.
WebDAV does not have any built-semantics for paging. Once can certaily use query parameters, but the stock clients (Finder, Win Explorer, Nautilus) don't support it. So, we need some mechanism to reduce overall number of children to return in a collection. This is especially true of bluesky beamline data, where there may be tens or hundreds of thousands of runs in a single collection.