ubuntu-phone team mailing list archive

[Ken VanDine <ken.vandine@xxxxxxxxxxxxx>]

On Sun, Mar 8, 2015 at 10:39 PM, Robert Schroll <rschroll@xxxxxxxxx> wrote:

> On Sun, Mar 8, 2015 at 9:04 PM, Ken VanDine <ken.vandine@xxxxxxxxxxxxx>
> wrote:
>
>> On Fri, Feb 20, 2015 at 1:54 AM, Robert Schroll <rschroll@xxxxxxxxx>
>>> wrote:
>>>
>>>> 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!)
>>>>
>>>>
>> That's a bug, please file it.
>>
>
> Filed as #1429687.
>
>  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?
>>>>
>>>
>> All transfers should go into the HubIncoming if there is not ContentStore
>> set, it's not related to the ContentType.
>>
>
> In this case, the ContentStore is set, and it's still going into .cache.
> I've filed a bug at #1429691.  But if this is intended behavior, please
> close it.
>
>  No, it doesn't, we could provide a delete API similar to move on the
>> ContentItem.  Please file a bug requesting it.
>>
>
> Filed as #1429693.
>
>  This happens because there is no default for EBooks.  File Manager isn't
>> a default app (only on vivid for mako I think), so we can't rely on it.
>>
>
> I think it's also on the flo images (I don't remember installing it
> separately), so I didn't appreciate this.  Nonetheless, I guess I should
> file a bug with the file manager to make it an ebook exporter.  (Is there
> any way for an app to register as an exporter of everything?)


Currently you can register as a handler for everything, all actually only
exists in the QML bindings for getting all peers.  This could complicate
things just a bit, but thinking ahead for convergence we might have a good
use case.  Please file a bug for this as well.

>
>
>    Although, we should really fail the transfer if you request the default
>> peer for a type that has no default.  I'd appreciate a bug report for that
>> as well.
>>
>
> Filed as #1429695.
>
>  You can only set the ContentStore from the side receiving the content,
>> and before it has been charged.
>>
>
> And am I right in understanding that an app receiving a push import only
> gets the content after the transfer has been charged?
>
> If so, it seems that this severely hampers the usefulness of setting the
> ContentStore.  I assume that most apps will want to support both push and
> pull imports and will try to share code between those two.  If you have to
> be able to do file management for the push imports, it's probably going to
> be easier to use that same code for the pull imports, rather than using a
> ContentStore.
>

That's a good point, we could allow setting the ContentStore after charged
on the receiving end, which would effectively do the same thing as
ContentItem.move, however the code would be more consistent.  Good idea!
Please file a bug for that as well.

>
> I'd like to post this info to the mailing list, so anyone else with the
> same questions will be able to find the answers.  Would you like me to
> summarize things, or would you like to post answers yourself?
>
> Thanks,
> Robert
>
>
>
>