ubuntu-phone team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

On 10/25/2013 12:03 PM, Robert Schroll wrote:

...
> 
> 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.
> 
> 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...
> 

I think you are thinking too much about files. The design of Unity, scopes,
content-hub, etc is more about content and less about file names and locations.

I see several things here that will help you and others when they are implemented:
 * system file picker/dialog content provider for the content-hub. This is an
   unconfined process. Beru talks to content-hub, content-hub calls file
   picker, user chooses what to read, content-hub gives it to Beru. This might
   be a copy of the file or in the future a file handle. AIUI, the goal is to
   abstract those kinds of details away so app deverlopers don't have to worry
   about them
 * epub content provider for the content-hub. This is the equivalent of the
   gallery content provider for ebub files. Ie, it can be fancier/prettier/more
   useful then a traditional file dialog. Otherwise works just like above (fyi,
   you can see the content-hub in action by changing the background on the
   phone)
 * epub unity scope. This allows users to search for/within epub files and
   launch them directly in an app that can handle them
 * sharing to other apps implemented-- ie, you can share files from the file
   manager, browser, etc to Beru so it can read them

The main problem right now is everything isn't written yet. Specifically, I
think there is only one content provider: the gallery-app. More need to be
written but once more are written multiple content providers need to be handled
gracefully (ie, should the epub, fpub, gpub, or file picker be used?). Sharing
to other apps isn't implemented nor is there an epub scope (both would also need
a way for Beru to easily hook into them).

>> 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).
> 
> This approach seems completely counter-intuitive to me.  Is the rationale behind
> it documented somewhere?
> 
That is indeed counter-intuitive and is not the intent of the design, however it
would work at this moment in time. In the future the content-hub and scopes
solve this-- the user puts content wherever he/she wants and then can search for
it (scope), open it from within Beru (content-hub) or launch Beru from another
app (sharing) and Beru doesn't know or care about file locations of content.

I'm not on the Unity team so I can't give ETAs on when this stuff is going to
land. I can say that these problems are known though and mainly what Beru needs
is for someone to implement a content provider so Beru can just use
qtdeclarative5-ubuntu-content0.1 and let the magic happen.

-- 
Jamie Strandboge                 http://www.ubuntu.com/

Attachment: signature.asc
Description: OpenPGP digital signature