Hi Johan, OK, I'll change it probably tomorrow. On Tue, Jul 26, 2011 at 10:11 AM, Johan Hedberg <johan.hedberg@xxxxxxxxx> wrote: > Hi Bartosz, > > On Wed, Jul 06, 2011, Bartosz Szatkowski wrote: >> 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 >> >> 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). >> > >> > 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) >> >> Is there any conclusion ? :) >> Are we leaving it that way or changing it as Luiz suggested (array)? >> Or maybe something else? > > For things like name and class (I suppose a list of UUIDs can also come > through the OOB data?). I think a single method call taking a dictionary > would be best. For the hash and randomizer, we could either keep the > existing method, or just define new "Hash" and "Rand" dictionary > entries. Since it's likely that all of this data comes in the same > instant over OOB I'm leaning towards the later solution. > > Johan > -- 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
