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

V2? Indeed #597

Open
puellanivis opened this issue Sep 30, 2024 · 0 comments
Open

V2? Indeed #597

puellanivis opened this issue Sep 30, 2024 · 0 comments

Comments

@puellanivis
Copy link
Collaborator

puellanivis commented Sep 30, 2024

I’ve finally gotten into the muck and got the work done to push out a v2 API.

This is right now just a preview, so we can look at things in a potentially breaking change manner, to see where we need to improve things, and invite discussion on the design.

The client copies much closer the os package, particularly with the OpenFile call, and reduces a lot of the repetitious code. It also uses generics, so we’re setting a new minimum version that can use our package. 🙈

The server on the other side is mimicking the gRPC framing for general instructions, but still remains the sort of os.File mimickry for Files. It does split Files and Directories, even though I’m not sure any implementation actually truly cares about this. But the design should allow one to force this distinction, if they want to make such a strict implementation. It is right now, strictly single threaded, but designed with an eye for how things could be spun off into concurrent tasks.

A local filesystem server is implemented as a subpackage, which is also useful as a demonstration of how to implement the new server interface. This removes the need for an in-memory filesystem, but that’s also something we could add back in, if there is significant demand.

Also, I took the time to read up every single supported Statfs implementation and figure out how that converts to that OS’s Statvfs. 🙃 That was fun. Also, we’re pulling in as much of the Stat_t as possible, which requires a pretty interesting array of OS-specific packages due to subtle naming differences.

Uh… yeah. Pile the bug tickets on, I want to know where I missed the mark, or messed up the implementation.

PS: Oh, I also want to add that all this work was possible because of the incredible work the people ahead of me did with this package. While I might not keep much of any of the original code, it taught me what works, and what was more kludgy than it was worth. So many decisions are made when we cannot know the ramifications later, like when the language puts out its own fs abstraction, and now we’re holding onto a deprecated design. But knowing now to not make those decisions now is worth more than gold! And I probably would have made the same choice, because it looked right at the time. We just cannot see the future. 🤷‍♀️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant