On Tue, Jul 5, 2011 at 11:59 AM, Bartosz Szatkowski <bulislaw@xxxxxxxxx> wrote: > On Tue, Jul 5, 2011 at 11:51 AM, Luiz Augusto von Dentz > <luiz.dentz@xxxxxxxxx> wrote: >> Hi Bartosz, >> >> On Tue, Jul 5, 2011 at 11:55 AM, Bartosz Szatkowski <bulislaw@xxxxxxxxx> wrote: >>> >>> Right, i'v discussed this approach with Johan and Szymon on freenode >>> -- i'v changed few things after that (mostly because implementing it >>> in AddRemoteData would break api, so i moved it to separate method) -- >>> maybe it would be a good idea to have this functionality now in this >>> form and change it when the api break would be possible (5.0?)? >>> >> >> Apparently the idea is to use this interface is to emulate a >> DeviceFound result, which I guess would make sense if the user pairs >> using the bt application/agent, but in the other hand this can be >> misused by application and they actually start overwriting device >> properties e.g. restore tool. So the question is how much do we trust >> application to provide this information without properly creating a >> device? To me it sounds that we either need the agent to actually >> accept this information as valid, which btw normally requires an >> object path to identify the device to query its properties, or we do >> it all together as I suggested in CreateDevice so we validate the >> information by pairing/connecting to the device. >> >> Btw, there is also the problem that D-Bus round trips are expensive >> and with such API one have to set one by one the properties to finally >> do a CreateDevice in the end, so at least the current design should >> make sure that an application can set all its known properties in one >> call e.g. SetRemoteProperties(string address, dict properties). >> >> -- >> Luiz Augusto von Dentz >> > > Yeah it sound good, but are we sure that there is need for setting > other parameters via OOB? The idea that was cleared on irc wast to add > CoD parameter to OOB.AddRemoteData(address, hash, randomizer, CoD) > > -- > Pozdrowienia, > Bartosz Szatkowski > Is there any conclusion ? :) Are we leaving it that way or changing it as Luiz suggested (array)? Or maybe something else? -- Pozdrowienia, Bartosz Szatkowski -- 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
