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

request-server: add lstat support #379

Merged
merged 1 commit into from
Sep 11, 2020
Merged

request-server: add lstat support #379

merged 1 commit into from
Sep 11, 2020

Conversation

drakkan
Copy link
Collaborator

@drakkan drakkan commented Sep 6, 2020

Add LstatFileLister, an optional interface for FileLister, if this
interface is implemented Lstat requests will call it otherwirse they
will be handled in the same way as Stat, as before

Add LstatFileLister, an optional interface for FileLister, if this
interface is implemented Lstat requests will call it otherwirse they
will be handled in the same way as Stat, as before
@drakkan
Copy link
Collaborator Author

drakkan commented Sep 8, 2020

@puellanivis now that we have clarified the implementations details, what do you think about this pull request?

For what I know this is one of the last missing pieces for the request-server, the other one is the support for the statvs packet.

What are your plans for 2.0? I'm thinking to completly remove server/request-server and implementing a single SFTPFs interface with optional extension interfaces. Basically a model very similar to the one proposed here.

I also would like to work on SFTP v6 support, using the new SFTPFs interface or extending the request-server. The server implementation is useless for my use case since it is only usable with local filesystem. Thank you

@puellanivis
Copy link
Collaborator

I need to once over the code again, just to make sure I haven’t missed anything, now that I know the way it is working.

For v2, I’ve been kind of thinking it might be good to separate the underlying network “wire format” away from the rest of the logic. So, providing a library that minimally exposes semantically-contained packets (you know, how we packed the structs just recently? We could change their order because the object had “semantic” scope, not “syntactic” scope.) Then ideally, if someone decides they would rather work with the raw packets or something, all power to them.

Then, on top of that low-level → lowest meaningful-semantic-packets, we use the semantic “atoms” to build the design of a new unified API similar to the io/fs package, which you linked to. When the io/fs project is rolled out, we might even develop a compatibility layer package that takes a compatible new API client, and makes it compatible with an io/fs directly, so you can “mount” or whatever necessary to get that to be compatible.

Ideas… but I haven’t really had much compelling force on such a massive refactor.

Copy link
Collaborator

@puellanivis puellanivis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that I understand things, I don’t see anything wrong.

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

Successfully merging this pull request may close these issues.

2 participants