Thank you, thank you, thank you! This is exactly the explanation I've
been searching for, and I've felt stupid not being able to find it.
Basically, the answer is to wait -- we're not seeing the full picture
yet.
A few more questions while we're waiting:
1) When we get to the point where apps get "pure" content, will there
be some way for them to identify that content to request it again
later? Beru has a list of books ordered by last reading date. Right
now, the books are identified by their filename. Will there be a
similar way when we just get a file handle, for example, that we can
remember the content ID and ask for it again later?
2) Will all of this work if you're not running Unity? If I want Beru
to work for other DEs, will I need two code paths, one to handle file
system access, the other to handle content hub access?
3) While we're waiting for all of this to happen, does it make sense to
give apps access to a "Content" directory in the user's home directory?
There would be no guarantee of safety or persistence of data stored
here, but I'm not counting on that for epub files in Beru.
Potentially, this could be turned into a FUSE filesystem backed by the
Content Hub once that's ready.
Thanks again,
Robert
On Fri, Oct 25, 2013 at 3:01 PM, Jamie Strandboge <ja...@canonical.com>
wrote:
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/
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help : https://help.launchpad.net/ListHelp
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help : https://help.launchpad.net/ListHelp
