$ show messense/aliyundrive-webdav
aliyundrive-webdav is a WebDAV server application that bridges WebDAV clients (like Infuse, nPlayer) with AliyunDrive (Alibaba Cloud Drive) storage. The system is built in Rust and uses the dav-server crate as its WebDAV foundation. Key functionality includes: authenticating with AliyunDrive via refresh tokens (obtained through command line, environment variables, or QR code login), translating WebDAV operations (PROPFIND, GET, PUT, etc.) to AliyunDrive API calls, implementing caching for directory listings to reduce API calls, handling file uploads via chunked resumable uploads, and providing automatic token refresh in the background. The architecture consists of modular components: cache (directory entry caching), drive (AliyunDrive API communication), login (QR code authentication flow), vfs (virtual file system layer), and webdav (server implementation and auth). External dependencies include the AliyunDrive API, reqwest, tokio, tracing, clap, moka, dashmap, serde, and optional TLS dependencies. The application is actively maintained with frequent commits, CI/CD pipelines for multi-platform builds, and support for Docker, Snap, OpenWrt, and systemd deployments.
The LLM identified 2 files worth highlighting for reuse:
Implements a generic caching layer for directory entries using Moka with TTL-based expiration. The component is isolated (depends only on moka and tracing), demonstrates proper cache invalidation strategies (including parent directory invalidation on file changes), and could be extracted to any project needing simple TTL caching with minimal modification (would require making the struct generic over value type). Shows non-obvious skill in cache hierarchy management for filesystem-like structures.
Contains reusable TLS setup functions (tls_acceptor and private_keys) for configuring rustls with hyper servers. These functions are completely generic, self-contained, and demonstrate expertise in proper TLS configuration including ALPN protocol setup for HTTP/2 support. Another engineer could extract these functions into any hyper-based TLS server project with zero modification, as they only depend on standard libraries and the rustls-pemfile/tokio-rustls crates, taking only file paths as input and returning a configured TlsAcceptor.