On Wed, Sep 29, 2010 at 5:00 PM, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > Hi, > > On Wed, Sep 29, 2010 at 5:52 PM, Claudio Takahasi > <claudio.takahasi@xxxxxxxxxxxxx> wrote: >>> >>> What's the motivation of moving this into its own D-Bus interface? I >>> thought the plan was to abstract both traditional SDP and ATT behind the >>> same API in which case having this in the Device interface makes more >>> sense imho. >>> >>> Johan >>> >> >> Hi Johan, >> >> we forgot the SDP integration plan. Forget this patch. >> >> From the implementation point of view, implement inside the attrib >> client plugin was the easiest way, if we keep this property inside the >> Device interface a new function needs to be created in device.h to >> register the available primary services object paths. > > Well there is a more complicated way, which is to add support for > user_data per method/property, so a plugin could directly register > their methods and properties in e.g. Adapter and Device interfaces. Of > course this has drawbacks since the API could really became a mess > with plugins doing there thing carelessly, but in the other hand it > can greatly simplify the interfaces like Device.Disconnect() > propagation. > > Just a crazy idea I had late in the night :D > > -- > Luiz Augusto von Dentz > Computer Engineer > Please ignore this patch sequence. A proper pull request will be sent to the ML containing the last 3 patches only. This patch [PATCH 1/4] will be removed. Claudio -- 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
