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 -- 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
