-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Storage repository #1768
Storage repository #1768
Conversation
The underlying work to provide implementations of these methods has not been done yet pending discussion, so this will break the build. This also adds Destroy() as described in #1509, though again no implementation is defined yet. This also adds detailed comments to the members of the URI interface, to make it clear what is expected of URI implementations.
This will be immediately reverted, but if we decide to revive it for some reason, it might be a good starting point. I started writing this and then realized Go already has an RFC3986 implementation here: https://golang.org/pkg/net/url/ I plan to use that unless there is some reason to build out or own instead.
This reverts commit adf04ad.
In retrospect, there is a lot of redundancy In the prose of the given implementation. I will do a second pass to tidy it up at some point.
Note that I have veered much more towards @toaster 's (Tilo) proposal than I had originally. My change of heart is documented in the relevant proposal here: https://github.com/fyne-io/fyne/wiki/Proposal%3A-The-Fyne-URI-Philosophy I have decided not to implement URINotListable on the basis that URIOperationImpossible already encompasses it's purpose, and additionally I want to encourage people to use Listable() rather than just trying to List() and then checking the error. I decided to move List and Listable() into the Repository interface, though developers can always throw URIOperatioNotSupported if they are impossible to implement. I could be convinced to move them into their own ListableRepository interface to be optionally registered, but to keep them together (since you cannot have one without the other). This was discussed a little bit, but I am on the fence. Since I decided to go with more of Tilo's approach, I did not add Move() or Duplicate(). If folks have opinions on using these names versus Rename() and Copy(), please add them on the PR.
Per our meeting today, I am merging the existing work into the new `storage_repository` feature branch so @andydotxyz and I can collaborate more easily. We will open a new PR `storage_repository -> develop` soon. Despite what the GitHub UI may say, this does **not** affect the approval state of this PR as far as the core team is concerned.
As of eb6c773 I have stubbed out everything from the proposal. What remains is:
I had to diverge from the proposal in the following ways:
|
Another case where I needed to differ: when we removed We also did not discuss if we intended to keep or deprecate |
I have realized that we never properly discussed what to do with |
Most notably, I have renamed RepositoryForURI() to RegisteredRepository(), to placate the linter.
I feel the divergences are acceptable. If it was added in 1.4 all we can do is deprecate it, I think? Otherwise, yes, I (as a Developer) one way to Create (New) and one way to Get (Parse) a URI. So far I'm happy with your approaches / mediations. |
AFAIK, policy is that it stays in for at least one major release.
Minor note - I changed |
NewFileURI is indeed very common. It delegates to NewURI. I don't think we can move NewFileURI to ParseFileURI as that isn't really what it's doing. |
What was the error? I don't think RegisteredRepository really describes the action. RepositoryForScheme would be more accurate. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The comment to code ratio is incredible!
Added a few comments of items that are more obvious to me from reading this PR than were from reading the wiki spec.
Great work Charles!
It also handles back-slashes on Windows, which we probably want to keep working for usability even if it's not in the spec.
|
What about |
I don't think this is a significant risk, since we don't ever recurse, other than I guess in file dialog where the user presumably knows what's going on. As it stands, I think this is a good thing to have in mind, but I view this as a path normalization thing, which we agreed to punt to the future. |
Decision on Directory Creation (
|
I think your issue should be fixed. As of d95d323 I am using I will raise the issue upstream and see what the author of the parser says. RFC396 uses this style of URI as an example explicitly (IETF RFC3986, §1.1 pp. 5). Edit: issue opened upstream. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PR is looking good, only one unresolved comment remaining
@stuartmscott I think this is the only remaining comment thread that is open. It is solved to my satisfaction unless you had something else you wanted to discuss on that front? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@charlesdaniels what about #1768 (review)?
Co-authored-by: Stuart Scott <stuart.murray.scott@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missed a couple, but otherwise this PR looks good to go and should be able to merge tonight
I think the widget.Form failures are flakey, can you try re-run them?
|
You OK if I merge @stuartmscott ? |
Go ahead! |
|
||
// There was no repository registered, or it did not provide a parser | ||
|
||
// Ugly hack to work around fredbi/uri. Technically, something like |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NOTE: forgot to update this comment, but actually foo:///bar/baz
is totally valid and should give us /bar/baz
as the path. This is documented in the discussion thread on #1768.
This is a continuation of #1665. See also the proposal.
Divergences from the proposal
These are generally discussed in more detail, this section provides a summary and keeps track of them in one place with direct links.
repository.ForURI()
methodRepositoryForURI()
hereURIRootError
torepository
repository.CustomURIRepository
extension interface to allow overridingstorage.ParseURI()
behavioruri
and back-end logic forParseURI
andNewFileURI
intorepository
to avoid a circular import, and allowGeneric{Parent,Child}()
to callParseURI
CreateListable()
has been added toListableRepository
to allow directories to be created