-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Add a public api for apps to add mounts #12577
Conversation
if (isset($options['personal']) && $options['personal']) { | ||
$mounts[] = new PersonalMount($options['class'], $mountPoint, $options['options'], $loader); | ||
} else { | ||
$mounts[] = new Mount($options['class'], $mountPoint, $options['options'], $loader); |
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.
Is expecting a Loader
, you're passing an ILoader
. - IDE complains.
(same for PersonalMount
above)
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.
Fixed
This is going in the right direction but probably needs more work to find out whether we can reduce the number of classes/interfaces that work with storages and mount points. Just throwing a few ideas:
|
A single storage can belong to multiple mount points (i.e. external storage which is mounted for multiple users)
👍
I would rather keep it a separate class (composition) and have |
* @param \OCP\Files\Storage\ILoader $loader | ||
* @return \OCP\Files\Mount\IMount[] | ||
*/ | ||
public function getMountsForUser(IUser $user, ILoader $loader); |
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.
I wonder, should it rather be: instantiate a MountManager
with an injected IUser
, and then just call getMounts()
to get that user's mount ? This way every user has a different mount point. Unless you say this is needed to be able to switch between users due to shares ?
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.
Yes, because setting up mounts for multiple users is fairly common due to shares imo it makes more sense to have the user as argument here
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.
Ok, based on the explanation you gave above it makes sense. If IMountProvider is some kind of factory that will instantiate mounts, then it has to be global.
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.
Okay, so IMountProvider is the instance that the newer ext storage plugins will have to implement and register.
The providers are registered to the global IMountManager (aka IMountProviderCollection)
And then the filesystem code will ask the IMountManager to give a list of IMount for a given user. Got it.
So in general it means that what we call a mount point "IMount" is IStorage + storage Settings + scope (applicable user/group)
Hmmm... would it make sense to separate the scope/user from the storage config and put it on a different level ? Storage config should only be about settings like host, username, password, etc.
Maybe this could help remove the distinction between Mount and Storage and we could somehow merge them.
currently some apps out there are using following code piece to register external storage implementations: Is this already respected in this pr? THX |
@icewind1991 ^^ |
@DeepDiver1975 that's for another PR, this leaves the Config class intact for now |
Would be cool if you could post a diagram (even if scanned from paper). We could then reuse it later for the documentation. There are already too many classes and it's easy to lose the overview. |
0350ec3
to
1852ddc
Compare
@icewind1991 I hope you don't mind the various suggestions, I just wanted to make sure we considered these many alternatives 😄 |
Provides a general overview of the components and their relations. This PR introduces the Config section which is currently done by hooks #11091 introduces the Factory class which is currently done by both
|
Nice diagram! Thanks a lot, that clears out a bit 😄 |
* | ||
* @param string $mountPoint new mount point | ||
*/ | ||
public function setMountPoint($mountPoint); |
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.
Bringing back an older question: should the IMountPoint instance know where it is mounted ? Or should this be stores on a highler level, the mount manager ? But maybe that information is needed in this level already to be able to move mount points.
On the other hand you could say that FileInfo
represents a file and it also contains the full path, so might be fine.
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.
I would keep it at the current level so we have a single object that holds all info needed to use the mounted storage
27978a5
to
66d4422
Compare
66d4422
to
a369d78
Compare
The inspection completed: 6 new issues, 25 updated code elements |
@owncloud-bot retest this please |
🚀 Test PASSed. 🚀 |
@DeepDiver1975 @schiesbn @PVince81 can this be merged? |
👍 makes sense, as discussed |
👍 |
Add a public api for apps to add mounts
Is there a write up of the api? I assume that we need to doc and test this for 8.0. |
That's an internal API for application developers, so nothing directly exposed to the end-user. As far I know there is no documentation about this for developers, however there is owncloud-archive/documentation#693 to track this. |
What is meant by "public"? I thought that meant available to all, not just internal use. |
A public API refers to an API exposed to application developers. An internal API is just to be used by the core folks. This is just a programming API, not something exposed via REST / SOAP / etc ;-) |
It's the public PHP API - used by application developers. And yes this means we need to document this - just like a hell of other php classes - see http://api.owncloud.org/namespaces/OCP.Files.Config.html |
Well - that's why I linked to #12577 (comment) ;-) – But there is no need that @jnfrmarks tests this IMHO |
indeed - nothing to take care of from an QA perspective |
This adds a public api which apps can use to add additional mountpoints in a more structured way then listening to hooks.
First PR for #12216
cc @PVince81 @DeepDiver1975