ubuntu-phone team mailing list archive

[Thomas Voß <thomas.voss@xxxxxxxxxxxxx>]

On Fri, Oct 25, 2013 at 7:03 PM, Robert Schroll <rschroll@xxxxxxxxx> wrote:
> Hi all,
>
> Thanks for the many replies, all.  It's a bit overwhelming, and I fear I may
> have missed something.  I'm going to try to summarize; please correct my
> mistakes:
>
> 1) There's no way to do what I want to do right now.
> 2) The content hub may provide the capabilities I want in the future, but
> this may not look like file access.
> 3) There may be additional ways to access the file system in the far future.
>
> As several of you have correctly surmised, this is for my epub reader Beru
> [1], which is currently limited to reading epubs stored in
> ~/.local/share/com.ubuntu.developer.rschroll.beru/, which isn't exactly
> convenient for the user to access.  But I asked this in general, because I
> don't want an epub-specific solution.  I want something that will work for
> anyone who's trying to build a viewer for Ubuntu Touch.
>
> Let me try to clarify a few points:
>
>
> Jamie Strandboge wrote:
>>
>> your app would only get a copy of the file in the app-specific directory
>> but no way to sync the file back out to its original location (in the
>> future, we should/may also support passing a file descriptor instead of a
>> full copy-- but this is an implementation detail that won't help your use
>> case).
>>
> [...]
>
>> In short, your use case falls into the category of 'backup software' and
>> backup software is not supported by the appstore at this time.
>>
>
> You're crediting me with too much ambition.  I don't want to modify or keep
> a copy of the epub files, I just want to read them.  The write access I want
> is to be able to download new epub files, but I'm less concerned about that
> (at the moment).
>
>
> Marc Deslauriers wrote:
>>
>> The first message in this thread sounds like he wants to access arbitrary
>> directories in the user's home folder. His original post however seems to
>> indicate he wants his ebook reader to be able to read and write ebooks
>> into
>> arbitrary locations in the user's home directory.
>>
>
> I'd prefer arbitrary locations, to allow the user to choose where to save
> their files and to allow for run-time localization.  But if we restrict it
> to a give sub-directory at compile time, that wouldn't be the worst thing in
> the world.
>

File-based content mgmt does not work very well on a phone. It should
be considered last resort and we are emphasizing this approach by
replacing vanilla file-open-dialogs with the content picking
infrastructure.

> Perhaps I'm thinking too much about files because that's what I'm used to.
> What I really want to do is access content that the user already has on the
> device and add additional content for the user to take off the device.  I
> had thought that's what the Content Hub was about, but...
>

The content hub does not know anything about content at all, it is
just a dispatcher/mediator between a content source app and a content
sink app.
>
>> Our application security model has each application owning its own data,
>> and
>> sharing it with other applications. In other words, the ebook reader
>> should be storing its files in its own directory, and offering them to other
>> applications via the content hub.
>>
>
> How does this work for content the user already has?  The main point of Beru
> is to let the user read the epubs the user already owns.  Can the user only
> copy the content over after they've chosen which reader to use?  That seems
> backwards.  Furthermore, what if I become evil (well, more evil than usual)
> and stop offering Beru's books to other apps?  This locks users into using
> Beru (or forces them to wade through hidden directories to recover their
> content).
>

Yes, content should always be owned by an app, with the user
associating content with apps instead of files.
The idea here is that a file-based mgmt just does not work well in a
phone-scenario and we are not exposing it as primary interface to
users. For that, the content hub comes into play for importing and
exporting content from one app to the other. Right now, it is always a
deep-copy but no matter in what direction we evolve the content hub
(most likely switching to a copy-on-write model), we will retain the
principle of "content owned by app".

If Beru at a future point in time decides to go evil and force content
to its own silo, the user is likely to uninstall it. One possible
approach then could be to transfer ownership of all books hidden away
by Beru to an app that is selected by the user. This could either be
another ebook reader, or, if things fail: a fallback file mgmt app
that surfaces the respective files again.

As I understand your use-case, this approach would solve the issue.
What do you think?

HTH,

  Thomas

> This approach seems completely counter-intuitive to me.  Is the rationale
> behind it documented somewhere?
>
>
> Michael Zanetti wrote:
>>
>> On Friday 25 October 2013 08:13:20 Marc Deslauriers wrote:
>>
> ‘5’
>
>> Oh, nice. What is the problem then why Robert's use cases don't work?
>>
>
> One problem is that there's not "epub_files" policy.  But even if there was,
> it doesn't solve the general case for fpub files, gpub files, etc.
>
>
> Michael Zanetti wrote:
>>
>> Wouldn't it make sense to have such a policy group for the "Documents"
>> folder? that would probably be just what Robert needs, no? Given that eBooks
>> (which I think is Robert'main use case) are quite big (in terms of
>> distribution) nowadays I could even imagine adding a ~/Books folder with
>> appropriate capabilities could make sense. What do you think?
>>
> When I first submitted Beru, I asked for read and write access to ~/Books.
> This was denied.  But again, this is a special-case solution to what seems
> to me to be a general problem.
>
> Thanks for the answers,
> Robert
>
> [1] rschroll.github.io/beru/
>
>
>
>
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp