Hi all,
I would like to propose some changes in obex-client's D-Bus API,
refactoring parts of the existing API and rewriting others.
The main goals would be the following:
- Higher level representation of devices and sessions, following
the BlueZ style.
- OPP operations wrapped into a specific session type, just like
the rest.
- Transfer objects are created always, making the API more orthogonal.
- Content of the pulled files is written to a file, avoiding dbus
overhead.
- Removal of agent, since all requests are locally initiated.
- Transfer progress reported using unicast signals to transfer
initiator.
Given that the diff would be quite unreadable, I attach the modified
'client-api.txt' document.
Please consider this as a first draft, open for discussion. I hope at
least some of these points are valid.
Cheers,
Mikel
Hi Mikel,
On Mon, Nov 21, 2011 at 6:36 PM, Mikel Astiz <[email protected]> wrote:
> Hi all,
>
> I would like to propose some changes in obex-client's D-Bus API, refactoring
> parts of the existing API and rewriting others.
>
> The main goals would be the following:
>
> ? ?- Higher level representation of devices and sessions, following the
> BlueZ style.
Im fine with the representation of sessions, device representation may
not be a bad idea but Im afraid this would not work very well for OPP
since it doesn't require pairing the device may not exist so we have
to support connecting by address anyway which defeats the purpose of
having a device. On the other hand if we start creating devices for
every device found that would solve the problem with OPP and we would
be able to have e.g. Connect method per interface like we have in
BlueZ.
> ? ?- OPP operations wrapped into a specific session type, just like the
> rest.
It probably adds an extra round trip but it is much more clean that
the current methods we have, and we can separate it from the core
daemon and put it in a separate module.
> ? ?- Transfer objects are created always, making the API more orthogonal.
Yep
> ? ?- Content of the pulled files is written to a file, avoiding dbus
> overhead.
Yep
> ? ?- Removal of agent, since all requests are locally initiated.
I guess it can be useful if someone wants to watch the progress of the
transfers.
> ? ?- Transfer progress reported using unicast signals to transfer initiator.
Can be done, but I would like first to align the transfers with obexd.
--
Luiz Augusto von Dentz