D-Bus API of obex-client

D-Bus API of obex-client

[Mikel Astiz]

Hi all,

After some tests with the obex-client, I would like to ask some 
questions related to the D-Bus API:

1. Transfers for OBEX-specific mime types: in obc_transfer_register, 
these types are filtered out so no transfer is registered for them. Is 
this a matter of overhead only? I mean, for considerable transfers such 
as full phonebook downloads, it would still make sense to provide a 
transfer. First, you could track the progress, and second, you could 
cancel it. Am I missing any other reason not to want this registration?

2. External monitoring of the active transfers: currently the agent 
owning a session is the only component that is able to know about the 
ongoing transfers. However it could be interesting to signal these 
transfers publicly, so other "external" components can have knowledge of 
them. Typically a GUI could be showing the progress of a download (even 
though another component initiated it) but it could also be that certain 
components would like to react accordingly (example, cancel a download 
if A2DP starts).

In addition, this kind of API would be more consistent with the ones in 
BlueZ or oFono, meaning that any interested component can keep track 
(and modify) the state.

Cheers,
Mikel

Re: D-Bus API of obex-client

[Luiz Augusto von Dentz]

Hi Mikel,

On Thu, Nov 17, 2011 at 5:05 PM, Mikel Astiz <mikel.astiz@bmw-carit.de> wrote:
> Hi all,
>
> After some tests with the obex-client, I would like to ask some questions
> related to the D-Bus API:
>
> 1. Transfers for OBEX-specific mime types: in obc_transfer_register, these
> types are filtered out so no transfer is registered for them. Is this a
> matter of overhead only? I mean, for considerable transfers such as full
> phonebook downloads, it would still make sense to provide a transfer. First,
> you could track the progress, and second, you could cancel it. Am I missing
> any other reason not to want this registration?

Originally the transfer where meant only for big files, but it seems
we gonna be using it for MAP so I would thing that it could be made
useful for any object transfer. But note that we should change some
APIs so that they return the object transfer for tracking.

> 2. External monitoring of the active transfers: currently the agent owning a
> session is the only component that is able to know about the ongoing
> transfers. However it could be interesting to signal these transfers
> publicly, so other "external" components can have knowledge of them.
> Typically a GUI could be showing the progress of a download (even though
> another component initiated it) but it could also be that certain components
> would like to react accordingly (example, cancel a download if A2DP starts).

Emitting progress is a bit tricky, it can load the system a bit too
much so I would say doing direct method call is better, in fact we
should have 2 processes monitoring the transfer, the application who
requested it and the agent, just pick one of those to track the
progress. IIRC for meego harmattan this is done in the agent, which
imo is a good idea because it has to be running everytime.

> In addition, this kind of API would be more consistent with the ones in
> BlueZ or oFono, meaning that any interested component can keep track (and
> modify) the state.

You mean you want methods to list current transfers and signals, but
the agent should already know about them, and probably we don't want
other process to interfere with transfer they don't own so we decided
to keep it simple.

-- 
Luiz Augusto von Dentz