Return-Path: MIME-Version: 1.0 In-Reply-To: <1322143742-31182-1-git-send-email-mikel.astiz@bmw-carit.de> References: <1322143742-31182-1-git-send-email-mikel.astiz@bmw-carit.de> Date: Fri, 13 Jan 2012 16:24:48 +0200 Message-ID: Subject: Re: [RFC obexd 00/10] Major API changes in obex-client From: Luiz Augusto von Dentz To: Mikel Astiz Cc: linux-bluetooth@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-bluetooth-owner@vger.kernel.org List-ID: Hi Mikel, On Thu, Nov 24, 2011 at 4:08 PM, Mikel Astiz 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