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

Add a public api for apps to add mounts #12577

Merged
merged 2 commits into from
Dec 8, 2014
Merged

Conversation

icewind1991
Copy link
Contributor

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

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);
Copy link
Member

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)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed

@PVince81
Copy link
Contributor

PVince81 commented Dec 3, 2014

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:

  • If any mount point is a storage anyway, should we make the concept "mount point" and "storage" into a single class ? IStorageManager would be a collection or storages ?
    If we do keep them separate:
  • Instantiate a mount point/storage with a IStorageFactory (instead of ILoader).
  • if MountManager is a collection of mount points, could this be merged into the Filesystem class (or a future non-static Filesystem class/service ?)
  • ...

@icewind1991
Copy link
Contributor Author

If any mount point is a storage anyway, should we make the concept "mount point" and "storage" into a single class

A single storage can belong to multiple mount points (i.e. external storage which is mounted for multiple users)

Instantiate a mount point/storage with a IStorageFactory (instead of ILoader).

👍

if MountManager is a collection of mount points, could this be merged into the Filesystem class (or a future non-static Filesystem class/service ?)

I would rather keep it a separate class (composition) and have IMountManager as member of \OC\Files\Node\Root which would become the main "state" of the fs

* @param \OCP\Files\Storage\ILoader $loader
* @return \OCP\Files\Mount\IMount[]
*/
public function getMountsForUser(IUser $user, ILoader $loader);
Copy link
Contributor

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 ?

Copy link
Contributor Author

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

Copy link
Contributor

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.

Copy link
Contributor

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.

@DeepDiver1975
Copy link
Member

currently some apps out there are using following code piece to register external storage implementations:
https://github.com/owncloud/core/blob/master/apps/files_external/lib/config.php#L45
https://github.com/owncloud/core/blob/master/apps/files_external/appinfo/app.php#L45

Is this already respected in this pr?
Will this be addressed in a second pr?

THX

@DeepDiver1975
Copy link
Member

@icewind1991 ^^

@icewind1991
Copy link
Contributor Author

@DeepDiver1975 that's for another PR, this leaves the Config class intact for now

@PVince81
Copy link
Contributor

PVince81 commented Dec 3, 2014

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.

@PVince81
Copy link
Contributor

PVince81 commented Dec 3, 2014

@icewind1991 I hope you don't mind the various suggestions, I just wanted to make sure we considered these many alternatives 😄

@icewind1991
Copy link
Contributor Author

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 \OC\Files\Filesystem and \OC_Util

\OC\Files\Node\Root is the base of the "modern" filesystem api and is the alternative for the "old" filesystem api \OC\Files\Filesystem and \OC\Files\View

@PVince81
Copy link
Contributor

PVince81 commented Dec 3, 2014

Nice diagram! Thanks a lot, that clears out a bit 😄

*
* @param string $mountPoint new mount point
*/
public function setMountPoint($mountPoint);
Copy link
Contributor

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.

Copy link
Contributor Author

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

@icewind1991 icewind1991 force-pushed the public-mount-api branch 2 times, most recently from 27978a5 to 66d4422 Compare December 4, 2014 14:34
@scrutinizer-notifier
Copy link

The inspection completed: 6 new issues, 25 updated code elements

@icewind1991
Copy link
Contributor Author

@owncloud-bot retest this please

@ghost
Copy link

ghost commented Dec 5, 2014

🚀 Test PASSed. 🚀
Refer to this link for build results (access rights to CI server needed):
https://ci.owncloud.org//job/pull-request-analyser-ng-simple/3841/
🚀 Test PASSed. 🚀

@icewind1991
Copy link
Contributor Author

@DeepDiver1975 @schiesbn @PVince81 can this be merged?

@LukasReschke LukasReschke mentioned this pull request Dec 5, 2014
23 tasks
@PVince81
Copy link
Contributor

PVince81 commented Dec 8, 2014

👍 makes sense, as discussed

@LukasReschke
Copy link
Member

👍

LukasReschke added a commit that referenced this pull request Dec 8, 2014
Add a public api for apps to add mounts
@LukasReschke LukasReschke merged commit 25a87d4 into master Dec 8, 2014
@LukasReschke LukasReschke deleted the public-mount-api branch December 8, 2014 21:57
@jnfrmarks
Copy link

@LukasReschke

Is there a write up of the api? I assume that we need to doc and test this for 8.0.

@LukasReschke
Copy link
Member

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.

@jnfrmarks
Copy link

What is meant by "public"? I thought that meant available to all, not just internal use.

@LukasReschke
Copy link
Member

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 ;-)

@DeepDiver1975
Copy link
Member

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

@LukasReschke
Copy link
Member

Well - that's why I linked to #12577 (comment) ;-) – But there is no need that @jnfrmarks tests this IMHO

@DeepDiver1975
Copy link
Member

But there is no need that @jnfrmarks tests this IMHO

indeed - nothing to take care of from an QA perspective

@MorrisJobke MorrisJobke added this to the 8.0-current milestone Jan 23, 2015
@lock lock bot locked as resolved and limited conversation to collaborators Aug 14, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants