Re: [RFC obexd 00/10] Major API changes in obex-client

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Mikel,

On Thu, Nov 24, 2011 at 4:08 PM, Mikel Astiz <mikel.astiz@xxxxxxxxxxxx> wrote:
> This patch series splits the perviously proposed obex-client API into incremental changes. The goal is to agree on the desired API before starting with the implementation.
>
> There are some differences with respect to the previous proposal, mainly:
>
> - The representation of devices has been dropped for now and considered of lower priority.
>
> - Progress-reporting signals are not defined as unicast signals, assuming that the perfomance overhead might not be significant.
>
> - Some operations such as PhonebookAccess.List have not been changed either, although it would be possible (as included in the previous proposal) to also use a file-based transfer here.
>
> Also note that the Transfer interface has been left inside the client-specific API, but would ideally be shared with the server. This is something to be kept in mind now in the design of the API.
>
> Mikel Astiz (10):
>  client-doc: reformatted to fit in 80 columns
>  client-doc: copyright statement added
>  client-doc: minor formatting changes
>  client-doc: wrap OPP into specific session type
>  client-doc: replace parameter dict with conventional ones
>  client-doc: remove agent in favour of transfer signals
>  client-doc: ObjectPush sessions return transports
>  client-doc: FileTransfer sessions return transports
>  client-doc: PhonebookAccess sessions return transports
>  client-doc: Synchronization sessions return transports
>
>  doc/client-api.txt |  265 +++++++++++++++++++++++++++++-----------------------
>  1 files changed, 148 insertions(+), 117 deletions(-)
>

I will be doing some cleanups before we integrate this code, some are
based on your mega patch that  you have sent (actually it never made
to the list due to its size), but I would like to separate the
transport code to modules e.g. bluetooth like we did for obexd so the
session just call e.g. .connect/.disconnect and the driver takes care
of the transport details such as requesting a session and discovering
records, this should simplify quite a lot session.c

The only problem is how we gonna interpret the address, by default it
should be Bluetooth but perhaps we should support urls for other
transport e.g. usb://, how about that?

-- 
Luiz Augusto von Dentz
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux