ubuntu-phone team mailing list archive

[Robert Schroll <rschroll@xxxxxxxxx>]

On Thu, Feb 19, 2015 at 10:56 PM, Ken VanDine 
<ken.vandine@xxxxxxxxxxxxx> wrote:
> We use the HubIncoming as a cache to allow access to the file when a 
> ContentStore[1] wasn't set on the transfer request, and will get 
> purged automatically by the service.  If you specify a ContentStore, 
> the file will get copied to the location of the store.  For Beru, I'd 
> recommend setting the ContentStore on the ContentTransfer, to skip 
> the HubIncoming all together and save it to the file destination 
> automatically.

Aha -- this is what I was missing!  It felt weird to have to muck about 
with files, when I though the point of the content hub was that you 
didn't have to muck about with files.  If I use a ContentStore with 
scope: ContentScope.App, the imported file gets put in a sensible 
location (~/.local/share/<appid>/<contenttype>/<filename>).  But I do 
have some questions:

1) The content seems to be silently dropped if there's already a file 
with the same name in the destination folder.  It doesn't seem to check 
whether the files are the same; it just drops the file being imported 
and returns the path of the existing file.  Is this by design, or is it 
a bug?  (For my purposes, this is probably okay -- I don't expect 
duplicate file names.  But other use cases may find this very 
surprising!)

2) If I request ContentType.All, the content gets put in the 
HubIncoming cache, instead of in the .local/share.  Again, is this on 
purpose or a bug?

3) Does the content hub provide a way to delete imported content that I 
don't want?  Since there's no guarantee that the type of imported 
content is what you requested, I'll have to check it, and it doesn't 
make sense to keep around copies of files I can't read.  Obviously I 
can write a C++ plugin to delete these, but it'd be handy to be able to 
do it from the ContentItem.

4) Things are broken if I request ContentType.EBooks.  If I request it 
from the default peer, I just see the ContentHint spin until I hit 
cancel.  If I use a PeerPicker, it tells me there aren't any apps that 
can provide this content type.  I would have expected the File Manager 
to act as a fallback provider for all types.  (After all, it's 
perfectly happy to give me an epub file when I request any other 
content type.)

On Thu, Feb 19, 2015 at 6:12 PM, Jamie Strandboge <jamie@xxxxxxxxxxxxx> 
wrote:
> The current implementation doesn't address permanently sharing 
> _writable_ data
> between apps. It is not a simple problem to solve well (we want to 
> avoid things
> like shared data directories) and it is something that should 
> probably be
> discussed again. Permanently sharing _readonly_ (to the shared-with 
> app) data
> should not be a particularly difficult problem to solve if it isn't 
> already.

The problem that I'm actually trying to solve, as most of you have 
probably guessed by now, is being able to read ebooks with Beru that 
have not been loaded into Beru's special directory.  I don't want to 
alter it, so it does seem a bit strange that I have to make a copy to 
do this.  This means that we're wasting drive space on the copies, and 
the user can't reclaim all of that space just by deleting the files 
visible over MTP.

What I want is a way for Beru to tell the content hub, I only want read 
access.  The the content hub can return the original file path and do 
some voodoo behind the scenes to give me apparmor permissions to read 
that file.  I don't think there's a way to do that yet, but if there 
is, please tell me how!

I recognize that this means the owner of the content could alter or 
remove it without Beru knowing about it.  That's fine -- I specifically 
designed Beru so that it wouldn't assume books would always be 
available.

Thanks for the help,
Robert