On Tue, Apr 12, 2016 at 7:04 AM, Stefano Verzegnassi < stefano92....@gmail.com> wrote:
> Hi Bill, > > 2016-04-11 15:28 GMT+02:00 Bill Filler <bill.fil...@canonical.com>: > > Are you accessing the videos from File Manager and trying to open from > > there? If so, that is the problem (actualy a bug in File Manager). When > > clicking on the video from file manager it should request to open in > > media-player not import via the content-hub. > > I understand the logic behind what you're saying, but that doesn't > convince me. > It sounds to me like an admission that there's something wrong with > the content sharing concept in the Ubuntu platform, and that there's > even no standard in a short term for that. > Sorry, it's not an admission of a problem. Sounds like it's a sign that there is some confusion about the security and content sharing model on the platform which I can try to clear up. The default concept is that apps are silo'd and own their data in a location only they can access. No other apps can access another apps data in these cases. That is where the content-hub comes in. The content-hub's main purpose is to provide a secure mechanism for apps to transfer (i.e. copy) their data to another app, such that the other app gets a copy of the data and can store (or not) in it's own silo'd area. content-hub is not a "viewing" api by design, it's a data transfer api. However, there are some exceptions to the rule which complicates things. There are system level directories on the platform that are able to be accessed by the certain allowed apps (via app armor rules) and system level components, and the apps use these directories to access/store their data. Specifically ~/Pictures -> Gallery, MediaPlayer, Scopes ~/Videos -> Gallery, MediaPlayer, Scopes ~/Music -> Music Player, Scopes ~/SD-Card -> Gallery, MediaPlayer, Scopes, Camera ~/Documents -> Document Viewer (I believe?) url-dispatcher is different from content-hub, in that it's purpose is to request an app on the system to open a given url, with the assumption being the destination app has permission to access the specified url/resource, in order to "view" or open it in place. > > Why should file-manager implement an exception for a single content type? > So backing up yet again, the phone was designed without having a File Manager at all, as it's really in conflict to the notion of apps owning their own data. The app is not installed on the device by default for this reason. Having a single app, file-manager, which is allowed to access all of the data on the disk, is only granted with a special security permissions and the user has to enter their password. So file-manager is really a special case. That said, the file-manager needs to be aware of the above rules and use the appropriate api's depending on the case. It's unfortunately not one size fits all with our current model. Using the content-hub for everything which the file-manager currently does, by definition will perform a copy of the data. It works but is not optimal for data which lives in the special directories as it makes a copy. For content that lives in the special directories listed above, there could be options in the file-manager to "view" the content based on mime-type using url-dispatcher. This would cause the content to be viewed in place by the destination app without copy. Yes it is extra work in the file-manager, but there is no support in content-hub for this type of operation. Perhaps in the future content-hub api can be extended to support opening in place if the source and destination directories are the same, but this doesn't exist today. > > In the past, a similar request has been made by music-app developers: > if an user requires to open a file from ~/Music, file-manager should > use URL dispatcher instead of content-hub. > Right, for same reason as stated above. > > What prevents Document Viewer (talking for myself here) to make a > similar request, instead of being forced to rely on the file name and > the size of the imported file[1][2], and finalize the transfer without > copying the file if the app detects a similar file in ~/Documents? - > This is the workaround that it has been suggested and I've been forced > to implement for such scenario. > If we are talking about not copying the file that exists already, ideally that should be done by content-hub and not the app, so I agree. Will add a bug for this and see what is involved for adding it in the future. > > Being a not-preinstalled app, or a fully-confined one shouldn't be a > reason why an app should be forced to provide a bad user experience, > nor for being excluded from an app (file-manager) that it's the only > way for an user to access the whole file system. > > I know there are security concerns about exposing the content of the > device to third party apps. However, at least, there's no reason why > content-hub should create a new copy of a file for an app that it has > been already whitelisted (in the AppArmor profile) and authorized to > the access that specific path. > Agreed > > This topic has been systematically raised every N months, by someone > complaining her/his unsatisfying experience with content-hub. > No answer has been given, so I'd like to know if there's some plan or > on-going work for those bugs that have been reported years ago, since > no progress has been made. > We'll look at the possibility of extending content-hub for this type of support. Seems a big part of the unsatisfying user experience is coming from the way file-manager is currently implemented, and as pointed out there is another viable solution that has been proposed in the past, with bugs filed, so this should not be blocked. > e.g. > https://bugs.launchpad.net/ubuntu/+source/content-hub/+bug/1324985 This is in progress > > https://bugs.launchpad.net/ubuntu/+source/content-hub/+bug/1370687 > https://bugs.launchpad.net/ubuntu/+source/content-hub/+bug/1425955 These two bugs are not specifically related to the problem you are describing > > > > Cheers, > > Stefano > > > [1] > http://bazaar.launchpad.net/~ubuntu-docviewer-dev/ubuntu-docviewer-app/lo-viewer/view/head:/src/plugin/file-qml-plugin/docviewerutils.cpp#L138 > [2] > http://bazaar.launchpad.net/~ubuntu-docviewer-dev/ubuntu-docviewer-app/lo-viewer/view/head:/src/app/qml/common/ContentHubProxy.qml >
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
