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 _______________________________________________ gnome-os-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-os-list
