GNOME.org
 

Re: Initial ideas on portals for file access

On Fri, 2015-03-13 at 10:08 +0100, Alexander Larsson wrote:


How do you tell that it's the "same file"? It has the same path? 
How  would you end up pruning your whitelist of allowed apps for 
each path?


My mail was meant to be pretty abstract/highlevel, and as such 
handwaved over things like this. But, I think the most reasonable 
implementation of this (in terms of both what is technically 
possible and what the user would understand it to mean) is that 
"same file" means same pathname/url. I.e. if you saved a new 
revision its the "same" document, but if you "save as" its a new one.

We could have some kind of tracking of moves and try to keep the 
file be "the same" if you e.g. moved a file or renamed a parent 
directory. However, that is technically quite complicated and 
costly, and it is dubious in terms of whether the user actually 
meant for the file to be "the same" in the above sense.


Right. But I would probably expect an application being granted access 
to, say, a video, doesn't suddenly stop being able to access it once 
I've fixed a typo in the name.


 * Access to a new version of the file at the same place
 * Ability to replace the file with a new version
 * Access other files in the same location (say video subtitles)


That sounds iffy. It would be better if the application calling 
the  file chooser could ask for certain annex files, and the user 
could see  that those files are related.


I'm merely bringing up the requirements here, not saying we should 
allow this. I agree that we shouldn't just allow this with no user 
feedback, but on the other hand I can't really see a understandable 
UI that would allow such annex files. This is just a hard to solve 
problem.


For the video subtitles case, you could pass a list of mime-types that 
the chooser could "attach" along with the video file. I'm not sure how 
we could advertise that additional files are getting selected along 
with the video file though.

I think a bigger problem might be with document types where the assets 
aren't in the same file. For example, again with video, a Pitivi 
project would have a project file (which you'd open), and assets in 
the same directory.

<snip>

Passing the same cookie as the original application will make it  
difficult to revoke the photo touchup application's permissions on 
that photo.


Its not necessarily difficult. It all depends on how the permissions 
work. We could easily allow for the camera app to grant transient 
permissions to the other application, and then revoke it. Or, we 
could have the broker handle the cooperation and the touchup app not 
accessing the real file, like you propose.


My point being that using solely a cookie might not be good enough. It 
might be that the broker daemon needs to key off cookie + app 
identifier, not just cookie.


What would be nice though is if these two cases:
 * opening a photo in the file manager with the touchup app, granting
   access to that one file
 * Having the camera app chain out to the touchup app to allow
   touching up a photo we just took
were implemented with the same APIs to read/write the file inside 
the touchup app.


Yes, certainly.


I could imagine whatever daemon running in the background acting 
as  the broker for those apps.

                   Camera app (through user)
- I have this photo, I'd like to pass it to another app to get 
modified
                   Daemon
- Sure, there's your list of apps
                   Camera app (through user)
- This one, here's a read-only handle for the image
                   Photo touch-up app
- Here's some kittens and and bold text to put on top. All done, 
here's another read-only handle for another image, and the handle 
for  the original image.
                   Daemon
- Let me check whether that matches. Yep, still ok with Camera 
app. 
Camera app, there's your modified image corresponding to this one 
you  asked to modify.
                   Camera app
- Cheers. Storing that here. Or overwriting the original. What do 
you 
say user?


So, this seems to me like you want to be able to grant (transient) 
permissions to read/write a file to another app, and then redirect 
any updates to the side so that the "sending" app can do whatever it 
wants with the new one. Its kinda like a "grant copy-on-write 
rights" operation.


Pretty much. The photo touch-up app can't access the original file, 
but it can save it in its local storage if it wants, and send it back 
to the original application once modified.


* In wayland we don't have a great way to "parent" dialogs 
between
  client, so we can't make the file selector seem to be owned by
  the window that requested the file operation without some form
  of compositor help.



I think that the file selection window should be owned by the  
compositor/shell, and should be unspoofable. It's a permission  
granting job after all. It could be populated by the application 
in  some limited way for internal "sharing".


I kind of agree, but "unspoofable" in this context generally means 
some desktop level modal operation,


It doesn't have to be, but it needs to be doing something that the 
application itself can't.

<snip>

Anyway, this can be fleshed out more, but I'd love to hear some  
feedback on this first.


The Open/Save dialogues are kind of a special case of "Sharing". I 
would expect a way to open a URL, a Photo from the Photo library, 
etc.  to be one of 2 mechanisms, the pull one.

I think that the majority of interactions would instead be push 
ones.  Send this video file in my Mail to the video player, share 
the URL of  this web page to Twitter, open this PDF from the web 
to my Documents.

This doesn't need cookies, at worst a receipt that the data has 
been  received on the other end if you want to "move" it from one 
app to the  other.


It doesn't really need cookies, true. It could just stream the data 
back and forth without any reference to some underlying document 
file. However, if we allowed some form of cookie-based access to a 
file for this usecase that would probably be helpful. First of all, 
the sending app doesn't need any code to stream the data, it just 
grants right to a file it already has. Secondly, on the recieving 
side you can use the same APIs/code that you have when reading a 
document opened in some other way, also you can do things like seek 
and do partial reads rather than a full copy (in case the file was 
e.g. a large video).

So, the "cookie" is not all that interesting per se. But we want 
some kind of broker API here that is expressive enough that we can 
do all these things, while still protecting the boundaries between 
these apps.


Yes. There's some details here from our meeting with Allan and Dave 
last summer:
https://wiki.gnome.org/Design/OS/Sharing#Technical_Details

Cheers
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]