-
Notifications
You must be signed in to change notification settings - Fork 30k
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
FSProvider: dependency on hierarchical paths? #35135
Comments
Getting children in the explorer is done by resolving the file here |
@jrieken didn't you say at one point that we expect extension authors to return URIs that follow a disk scheme, e.g. there is hierarchy reflected in the URI. In other words, we would not expect URIs such as: Anyway, we do expect a hierarchy in all our calls to |
Well, yes and "hello, here comes reality" maybe no. One problem was that we were not able to get @joaomoreno's stats to show in the explorer and we were clueless why... So one guess was that the explorer depends on hierarchal paths. It's not clear if all providers can full-fill the requirement of such paths but it is valuable to know that we will have a hard time without them |
In my example, my URIs didn't represent the hierarchy the actual underlying model had. A parent's URI was not a prefix to all its children's URIs. |
This issue has been closed automatically because it needs more information and has not had recent activity. Please refer to our guidelines for filing issues. Thank you for your contributions. |
Closing as question, the answer seems to be "Yes, we depend on hierarchical uris..." |
Testing #35009
Maybe the Explorer has a requirement on hierarchical resources having hierarchical URIs...
The text was updated successfully, but these errors were encountered: