3:02 p.m.
Based on discussions with the Qt company, the D-Bus specification authors,
and members of the AGL community, we need to make some modifications to AMB
to resolve incompatibility issues between AMB and Qt that were uncovered.
Basically, we need a better mechanism for specifying what properties are
supported in a specified zone than we are using today. Existing SW expects
that a D-Bus Object's properties are the same for every instance of that
object across the entire service. (Today, AMB only exposes valid properties
for an object in a specified zone.)
The conversation on the AGL mailing list (
http://lists.linuxfoundation.org/pipermail/automotive-discussions/2015-De...)
has boiled down to three requirements as a new proposal:
1. An AMB Object will contain all properties that could exist in that
object. For example, if the AMB documentation specifies that object Foo has
properties Bar and Baz, every object Foo exposed on the D-Bus will have
properties Bar and Baz, regardless of whether or not they are valid for the
zone containing object Foo.
2. There will be no AMB Object in a zone not valid for that object and
exactly one AMB Object in each valid zone. (NOTE: This would deprecate
FindObjectsForZone, since there would only ever be one object within that
zone.)
3. Applications will be responsible for querying whether a property is
supported in a given zone. This will be done through a mandatory
"Supported" property which returns a list of property names that are
supported by the object.
This proposal is by no means final and is open to discussion. Thoughts?
Cheers,
Matthew
--
*Matthew Vick*
Linux C++ Engineer
Jaguar Land Rover North America, LLC
1419 NW 14th Ave, Portland, OR 97209
JaguarUSA.com <http://www.jaguarusa.com/index.html> | LandRoverUSA.com
<http://www.landrover.com/us/en/lr/>
3:29 p.m.
On Thu, Jan 28, 2016 at 3:02 PM Vick, Matthew <mvick(a)jaguarlandrover.com>
wrote:
Based on discussions with the Qt company, the D-Bus specification
authors,
and members of the AGL community, we need to make some modifications to AMB
to resolve incompatibility issues between AMB and Qt that were uncovered.
Basically, we need a better mechanism for specifying what properties are
supported in a specified zone than we are using today. Existing SW expects
that a D-Bus Object's properties are the same for every instance of that
object across the entire service. (Today, AMB only exposes valid properties
for an object in a specified zone.)
The conversation on the AGL mailing list (
http://lists.linuxfoundation.org/pipermail/automotive-discussions/2015-De...)
has boiled down to three requirements as a new proposal:
1. An AMB Object will contain all properties that could exist in that
object. For example, if the AMB documentation specifies that object Foo has
properties Bar and Baz, every object Foo exposed on the D-Bus will have
properties Bar and Baz, regardless of whether or not they are valid for the
zone containing object Foo.
2. There will be no AMB Object in a zone not valid for that object and
exactly one AMB Object in each valid zone. (NOTE: This would deprecate
FindObjectsForZone, since there would only ever be one object within that
zone.)
Isn't this already the case? FindObjectsForZone is a way to find a
property that shows up in multiple zones. For example, you could have
Climatecontrol in driver and passenger zones. To get the driver one, you'd
call FindObjectForZone with the driver zone.
We may need to throw an error if someone tries to register multiples of the
same property in the same zone.
3. Applications will be responsible for querying whether a property
is
supported in a given zone. This will be done through a mandatory
"Supported" property which returns a list of property names that are
supported by the object.
This proposal is by no means final and is open to discussion. Thoughts?
Cheers,
Matthew
--
*Matthew Vick*
Linux C++ Engineer
Jaguar Land Rover North America, LLC
1419 NW 14th Ave, Portland, OR 97209
JaguarUSA.com <http://www.jaguarusa.com/index.html> | LandRoverUSA.com
<http://www.landrover.com/us/en/lr/>
_______________________________________________
AMB mailing list
AMB(a)lists.01.org
https://lists.01.org/mailman/listinfo/amb
11:33 a.m.
On Thu, Jan 28, 2016 at 3:29 PM, Kevron Rees <tripzero.kev(a)gmail.com> wrote:
On Thu, Jan 28, 2016 at 3:02 PM Vick, Matthew <mvick(a)jaguarlandrover.com>
wrote:
> 2. There will be no AMB Object in a zone not valid for that object and
> exactly one AMB Object in each valid zone. (NOTE: This would deprecate
> FindObjectsForZone, since there would only ever be one object within that
> zone.)
>
Isn't this already the case? FindObjectsForZone is a way to find a
property that shows up in multiple zones. For example, you could have
Climatecontrol in driver and passenger zones. To get the driver one, you'd
call FindObjectForZone with the driver zone.
We may need to throw an error if someone tries to register multiples of
the same property in the same zone.
Perhaps I'm just mis-remembering the method (I haven't worked with AMB
since before the holidays), but I thought I remember a FindObjectsForZone
method to find all instances of an object within a zone. For example,
multiple plugins causing multiple objects to appear within the same zone to
account for multiple properties. That note can be dropped if it's
inapplicable/my memory is awful since the spirit of the requirement is
really "There's guaranteed to be only one object to represent some
functionality in a zone. For example, only one ClimateControl in zone 5."
1:05 p.m.
On Fri, Jan 29, 2016 at 11:33 AM Vick, Matthew <mvick(a)jaguarlandrover.com>
wrote:
On Thu, Jan 28, 2016 at 3:29 PM, Kevron Rees
<tripzero.kev(a)gmail.com>
wrote:
> On Thu, Jan 28, 2016 at 3:02 PM Vick, Matthew <mvick(a)jaguarlandrover.com>
> wrote:
>
2. There will be no AMB Object in a zone not valid for that object and
>> exactly one AMB Object in each valid zone. (NOTE: This would deprecate
>> FindObjectsForZone, since there would only ever be one object within that
>> zone.)
>>
>
> Isn't this already the case? FindObjectsForZone is a way to find a
> property that shows up in multiple zones. For example, you could have
> Climatecontrol in driver and passenger zones. To get the driver one, you'd
> call FindObjectForZone with the driver zone.
>
> We may need to throw an error if someone tries to register multiples of
> the same property in the same zone.
>
Perhaps I'm just mis-remembering the method (I haven't worked with AMB
since before the holidays), but I thought I remember a FindObjectsForZone
method to find all instances of an object within a zone. For example,
multiple plugins causing multiple objects to appear within the same zone to
account for multiple properties. That note can be dropped if it's
inapplicable/my memory is awful since the spirit of the requirement is
really "There's guaranteed to be only one object to represent some
functionality in a zone. For example, only one ClimateControl in zone 5."
FindObjectsForZone only returns one object. So if there is two instances
of ClimateControl in zone 5, the source plugin is doing somethings screwy
(or perhaps two source plugins with the same uuid? That shouldn't happen).
Suggestion 3 got snipped, but instead of adding a "Supported" call, 0.15
has the concept of Value Quality. One of the possible values for this is
"UncertainInitialValue" which seems appropriate to use for dbus properties
that show up but are not really supported.
1900
days inactive
1901
days old
3 comments
2 participants
participants (2)
-
Kevron Rees -
Vick, Matthew