Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible new architecture for resolving WebDAV paths #67

Open
jwodder opened this issue Feb 13, 2024 · 2 comments
Open

Possible new architecture for resolving WebDAV paths #67

jwodder opened this issue Feb 13, 2024 · 2 comments
Labels
code quality Nonfunctional improvements to the codebase under consideration Dev has not yet decided whether or how to implement

Comments

@jwodder
Copy link
Member

jwodder commented Feb 13, 2024

WIP design document for a new code architecture

  • Rename DandiDav to Dav

  • Give Dav a register(name: &Component, handler: Box<dyn DavHandler>, description: &str) -> Result<(), DuplicateNameError> method for registering a handler for a WebDAV hierarchy to serve under /{name}/

    • description is used as the "Type" value for the hierarchy in the root HTML view
    • As an alternative to boxing, the type of handler could instead be an enum using enum dispatch.
  • Add a DavHandler trait with the following methods:

    • get_resource(&self, path: Vec<Component>) -> Result<DavResource, DavError>
    • get_resource_with_children(&self, path: Vec<Component>) -> Result<DavResourceWithChildren, DavError>

    Note that path may be empty (i.e., when a client requests /{name}/), and so PurePath cannot be used here.

    Note that these methods will be async, which may have implications for boxability of trait objects; cf. https://blog.rust-lang.org/2023/12/21/async-fn-rpit-in-traits.html.

  • Add a DandiDav struct implementing DavHandler for serving resources under /dandisets/; move all code specific to /dandisets/ here

    • This struct will implement resolution of paths under /dandisets/, currently implemented by the current DandiDav type via DavPath
  • Add a ZarrMan struct implementing DavHandler for serving resources under /zarrs/

  • Idea: The internal implementations of the DavHandler types could traverse their hierarchies as follows:

    • Locations in a handler's hierarchy are represented by an enum with variants for different depths & similar (cf. DavPath and zarrman::ReqPath)

    • The handler instantiates a location enum with the root variant and then applies each component in path in turn by calling an into_child(self, name: Component) -> Result<Self, DavError> method

      • This method returns Err if it can be easily determined (sans IO) that the path so far is invalid/does not exist
    • Details for the final location are then retrieved based on the location enum's final state

  • Whose responsibility is it to prepend the /{name}/ component to hrefs in responses?

    • If the DavHandlers don't prepend it, what would the paths of their root collections be? None?
    • Give DavResource[WithChildren] a prepend_path(&mut self, path: &PureDirPath) method for calling by Dav after delegating to a handler?
    • Idea: Make name(&self) -> &'static str a method of DavHandler, and make it the DavHandlers' responsibility to prepend the name
      • This will be more reasonable if enum dispatch is used instead of boxing.
@jwodder jwodder added under consideration Dev has not yet decided whether or how to implement code quality Nonfunctional improvements to the codebase labels Feb 13, 2024
@yarikoptic
Copy link
Member

what is the motivation/goal?

@jwodder
Copy link
Member Author

jwodder commented Feb 14, 2024

@yarikoptic Cleaner code, separation of concerns, better ability to add more "top-level" services like /dandisets/ and /zarrs/ in the future, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code quality Nonfunctional improvements to the codebase under consideration Dev has not yet decided whether or how to implement
Projects
None yet
Development

No branches or pull requests

2 participants