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
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. 🤷♀️
The text was updated successfully, but these errors were encountered:
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 theOpenFile
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’sStatvfs
. 🙃 That was fun. Also, we’re pulling in as much of theStat_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. 🤷♀️The text was updated successfully, but these errors were encountered: