Re: Initial ideas on portals for file access

[Alexander Larsson <alexl redhat com>]

On mån, 2015-03-09 at 19:06 -0400, Matthias Clasen wrote:
> Hey Alex,
>
> thanks for writing this up! Overall the Open/Save api looks about as I
> would expect. A few thoughts:
>
> Your api is more or less focused on local files. But interesting
> content these days very often resides elsewhere, in your various
> online accounts.
> https://wiki.gnome.org/Design/Whiteboards/ApplicationSandboxing
> describes the operations as 'Content Selection' and 'Export' - do you
> think that we should treat all of this under the Open()/Save() api ?
> Your mention of a downloading step seems to hint in that direction.

Yeah, I don't think this is necessarily backed by local files only. The
main idea is that we have an opaque cookie, which the app does not
actually know where it is from, and that i/o operations on it happens
like on a local file. This means we can easily back the file on anything
as long as we can download/upload to a local copy, because we assume no
particular pathname semantics or anything.

> Having an explicit Save() API seems to be a bit counter towards our
> general trend of saying that state should always be persisted, to
> avoid dataloss and to make applications stateless. I guess we assume
> applications to persist their state in their 'playground' area and
> only call Save() when the user wants to explicitly 'export' the
> changes from the application ?

Yeah, I'm not sure the "Save" name is ideal. What it really is is "here
is a new version of the file contents". Maybe something like
ReplaceContents() is better. That said, do we really want applications
to start saving to files automatically all the time, even without
triggering a save operation? I think a lot of people may be surprised by
that behaviour. And if so, how often do we save them? We can't save all
the time, that would be pretty poor performance.

Maybe we can make the API easier to cater to the kind of behaviour you
describe though, by having the cookie also track the "app copy" of the
file and then have "save" be the "export" operation instead, which
copies the app copy to the external one?

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's a shy dishevelled librarian in a wheelchair. She's a man-hating 
bisexual widow from a secret island of warrior women. They fight crime!