Hi Scott,
>>> This patch proposes an extension to the D-Bus Device API to allow
>>> an application access to the last EIR data received from a device
>>> in inquiry or advertising mode.
>>>
>> in general I have no objections in exposing the EIR and AD information. However I do not like to use EIR as property key. I know that on mgmt API we simply went with EIR_Data, but on the D-Bus API we most likely need to find a name that is a bit more generic and allows to represent EIR and AD information.
>>
>
> Thinking about this a little bit more, I'm not sure this should be a
> Device property either. The advertisement data isn't really a property
> of the device, but a property of the advertisement itself.
>
> A peripheral could theoretically send different advertisements, a
> weird example might be a peripheral sending a non-connectable
> undirected advertisement generally, and a connectable directed
> advertisement to us directly, with different AD.
that is indeed possible. They can also interleave them with one time targeting a different central.
Keep in mind that there is also something called service solicitation. Meaning a peripheral start indicated that it want a device with service UUID x to find us. iOS is for example using that to filter for the Notification Center stuff.
> This seems to fold back nicely into the discussion about a "Find
> Devices" API, intended for applications and separate from the
> StartDiscovery API. If that were an "agent" mode, it could look
> something like this:
>
> <- Search( { Data: "FF4C000214" }, agent_object_path )
> -> DeviceFound( device_object_path, data )
> -> DeviceFound( device_object_path, data )
> -> DeviceFound( device_object_path, data )
>
> Where data in the agent method is the unparsed advertisement data, if
> the application is interested in it. The above example is looking for
> an iBeacon by presence of a specific data structure, so the app
> probably wants the unparsed data parameter and doesn't care so much
> about the object path.
>
> But looking for heart rate monitors might be:
>
> <- Search( { UUID: "180D" }, agent_object_path )
> -> DeviceFound( device_object_path, data )
> -> DeviceFound( device_object_path, data )
> -> DeviceFound( device_object_path, data )
>
> In which case the application probably just wants the device object path.
>
>
> If this is broadly along the lines you're thinking, I'll draft a doc
> to begin discussion.
I think this looks pretty along the lines what I am looking for. However I was thinking in a bit more detail likes this:
<- Search method call
-> New Device object / Updated device object
-> New Device object / Updated device object
-> Search method return -> array of objects with properties
So you can treat the search dead simple and just display the results. However that way you can not monitor progress. If you want to monitor progress while search is running, you need to monitor changes to the device objects.
Regards
Marcel
--
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
