W3C home > Mailing lists > Public > public-autowebplatform@w3.org > June 2014

RE: Fw: Comments on VehicleInterface and Availability (Vadim's proposal)

From: Abramski, Adam M <adam.m.abramski@intel.com>
Date: Thu, 12 Jun 2014 18:12:41 +0000
To: Vadim Draluk <vadim@draluk.net>, "Rees, Kevron M" <kevron.m.rees@intel.com>
CC: "public-autowebplatform@w3.org" <public-autowebplatform@w3.org>, "internal-autowebplatform@w3.org" <internal-autowebplatform@w3.org>
Message-ID: <6AB32C125D193D47AE66073666ED3B5E34B0FB95@ORSMSX105.amr.corp.intel.com>
Ah sorry I missed the context in which you made the reference to RSE.  Thanks!
Adam

From: Vadim Draluk [mailto:vadim@draluk.net]
Sent: Wednesday, June 11, 2014 10:44 PM
To: Abramski, Adam M; Rees, Kevron M
Cc: public-autowebplatform@w3.org; internal-autowebplatform@w3.org
Subject: Re: Fw: Comments on VehicleInterface and Availability (Vadim's proposal)

Adam,

I did not mean my statement as an across-the-board judgement wrt zoning. It was meant only in the specific context of faceplate and steering wheel buttons. Otherwise zoning is a useful concept that has its place in vehicle APIs

Cheers

Vadim

________________________________
From: "Abramski, Adam M" <adam.m.abramski@intel.com<mailto:adam.m.abramski@intel.com>>
To: Vadim Draluk <vadim@draluk.net<mailto:vadim@draluk.net>>; "Rees, Kevron M" <kevron.m.rees@intel.com<mailto:kevron.m.rees@intel.com>>
Cc: "public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>" <public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>>; "internal-autowebplatform@w3.org<mailto:internal-autowebplatform@w3.org>" <internal-autowebplatform@w3.org<mailto:internal-autowebplatform@w3.org>>
Sent: Wednesday, June 11, 2014 6:27 PM
Subject: RE: Fw: Comments on VehicleInterface and Availability (Vadim's proposal)

Hi Vadim

I don’t think zoning is just about RSE, you can have sensors that are located in different zones like tire pressure…

Sincerely,
Adam

From: Vadim Draluk [mailto:vadim@draluk.net]
Sent: Wednesday, June 11, 2014 5:17 PM
To: Rees, Kevron M
Cc: public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>; internal-autowebplatform@w3.org<mailto:internal-autowebplatform@w3.org>
Subject: Re: Fw: Comments on VehicleInterface and Availability (Vadim's proposal)

We can do it this way too, it can be part of Vehicle Data. I personally really don't care for zoning in this case (expecting rear-seat entertainment to go the way of dinosaurs), but they do not do much harm either

________________________________
From: "Rees, Kevron" <kevron.m.rees@intel.com<mailto:kevron.m.rees@intel.com>>
To: Vadim Draluk <vadim@draluk.net<mailto:vadim@draluk.net>>
Cc: "public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>" <public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>>; "internal-autowebplatform@w3.org<mailto:internal-autowebplatform@w3.org>" <internal-autowebplatform@w3.org<mailto:internal-autowebplatform@w3.org>>
Sent: Wednesday, June 11, 2014 4:47 PM
Subject: Re: Fw: Comments on VehicleInterface and Availability (Vadim's proposal)

On Wed, Jun 11, 2014 at 4:25 PM, Vadim Draluk <vadim@draluk.net<mailto:vadim@draluk.net>> wrote:
> Kevron,
>
> I do not understand your button handling proposal. How does one subscribe
> to, say, the 5-way events under your approach?

vehicle.buttonEvent.subscribe(function(data) {
  console.log(data.button + " was pressed " + data.state);

  if(data.button == "up")
      /// up();
});

A possible weakness in this approach is that here we are listening to
effectively ALL button events.  Where your approach doesn't allow you
to listen for individual buttons (ie, just the "voice rec" button), it
could.  With a addButtonPressedListener(VehicleButton button,
ButtonPressCallback callback) change you could.  Your approach also
doesn't seem to allow for zoning.

> To be buttons are quite
> different from sugnal or configuration attributes, thus subject to separate
> provisions under the API.
>

I might be missing something, but any justification I can think of for
making ButtonEvent a unique API could not also apply to many of the
interfaces in the vehicle data spec.  But I'm probably missing
something.  Buttons do have "current values".  They are just in an
unpressed state.  This state should also be available to apps, IMO.


> Btw, just noticed a typo on page 15 of my doc: the interface is meant to be
> VehicleButtonInterface, not VehicleSignalInterface (a lazy cut-and-paste
> gone bad...)
>
> Cheers
>
> Vadim
>
> ________________________________
> From: "Rees, Kevron" <kevron.m.rees@intel.com<mailto:kevron.m.rees@intel.com>>
> To: Vadim Draluk <vadim@draluk.net<mailto:vadim@draluk.net>>; "public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>"
> <public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>>
> Cc: "internal-autowebplatform@w3.org<mailto:internal-autowebplatform@w3.org>" <internal-autowebplatform@w3.org<mailto:internal-autowebplatform@w3.org>>
> Sent: Wednesday, June 11, 2014 3:53 PM
>
> Subject: Re: Fw: Comments on VehicleInterface and Availability (Vadim's
> proposal)
>
> forwarding to public as well...  Vadim, are you subscribed to the
> public list?  Maybe that's why it's bouncing?
>
> On Wed, Jun 11, 2014 at 3:52 PM, Rees, Kevron <kevron.m.rees@intel.com<mailto:kevron.m.rees@intel.com>>
> wrote:
>> Thanks.  I see it now.  I'm okay with the VehicleCommonDataType
>> removal if it causes less confusion.  Another editor in another group
>> suggested also getting rid of it, but for different reasons (it's a
>> small interface and therefore doesn't add much).  The security section
>> seems to have formatting issues.  The navigation is messed up when
>> viewing in word.... but the content looks good.
>>
>> For VehicleButton, why isn't VehicleButton just another interface in
>> the Data specification?  I imagine it would look something like this:
>>
>> interface ButtonEvent
>> {
>>    readonly attribute VehicleButton button;
>>    readonly attribute PressType state; // press, longpress, ...
>> }
>>
>> partial interface Vehicle
>> {
>>  readonly attribute VehicleSignalInterface buttonEvent;
>> }
>>
>> The above leaves open the possibility for zoning.  If rear displays
>> have physical buttons, this would be useful.
>>
>> I'm actually really glad you brought this up.  I realized last week
>> that we had this and some other, IMHO, critical data attributes
>> missing from the data spec.
>>
>>
>>
>> On Wed, Jun 11, 2014 at 3:13 PM, Vadim Draluk <vadim@draluk.net<mailto:vadim@draluk.net>> wrote:
>>> I've sent the doc twice, the second version from 6/6 has security and
>>> button
>>> processing changes
>>>
>>> Just in case, attaching it here too
>>>
>>> ________________________________
>>> From: "Rees, Kevron" <kevron.m.rees@intel.com<mailto:kevron.m.rees@intel.com>>
>>>
>>> To: Vadim Draluk <vadim@draluk.net<mailto:vadim@draluk.net>>
>>> Cc: "internal-autowebplatform@w3.org<mailto:internal-autowebplatform@w3.org>" <internal-autowebplatform@w3.org<mailto:internal-autowebplatform@w3.org>>
>>> Sent: Wednesday, June 11, 2014 3:04 PM
>>> Subject: Re: Fw: Comments on VehicleInterface and Availability (Vadim's
>>> proposal)
>>>
>>> On Wed, Jun 11, 2014 at 2:34 PM, Vadim Draluk <vadim@draluk.net<mailto:vadim@draluk.net>> wrote:
>>>> Resending my response as my message to the public list bounced, as usual
>>>>
>>>> ----- Forwarded Message -----
>>>> From: Vadim Draluk <vadim@draluk.net<mailto:vadim@draluk.net>>
>>>> To: "Rees, Kevron" <kevron.m.rees@intel.com<mailto:kevron.m.rees@intel.com>>;
>>>> "public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>" <public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>>
>>>> Sent: Wednesday, June 11, 2014 2:21 PM
>>>> Subject: Re: Comments on VehicleInterface and Availability (Vadim's
>>>> proposal)
>>>>
>>>> Kevron,
>>>>
>>>> thanks a lot for your comments.
>>>>
>>>> The attributeName should be there for availability, IMO, and it's
>>>> absence
>>>> in
>>>> examples is my bad. The reason is that availability is something that is
>>>> likely to be addressed at individual attribute level, so, unless each
>>>> interface has only one attribute, we have to have this parameter.
>>>>
>>>> I'm fine with renaming methods as you see fit.
>>>>
>>>> As to availability listener, there may be some misunderstanding here. I
>>>> have
>>>> not introduced it (do not particularly like it either, but can live with
>>>> it), it's been there in the previous version. What I did add was
>>>> listening
>>>> to buttons, which are different from signals because they do not have
>>>> current values. There's also an enum called VehicleButton that has an
>>>> initial list of such buttons I have assembled.
>>>>
>>>
>>> Is this in the data spec doc?  I have not looked at that one yet (if
>>> there is one).
>>>
>>>> Would also like to point out deletion of the VehicleCommonDataType. I
>>>> think
>>>> it to be redundant, but wanted a confirmation, especially because this
>>>> change would result in a lot of editing in the Vehicle Data doc.
>>>>
>>>> Finally, would also appreciate thoughts on the newly introduces Security
>>>> wording
>>>>
>>>
>>> I wonder if there is a newer version of the vehicle info spec.  The
>>> security section in the version i have looks unchanged.
>>>
>>>
>>>> Cheers
>>>>
>>>> Vadim
>>>>
>>>> ________________________________
>>>> From: "Rees, Kevron" <kevron.m.rees@intel.com<mailto:kevron.m.rees@intel.com>>
>>>> To: "public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>" <public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>>
>>>> Sent: Wednesday, June 11, 2014 2:05 PM
>>>> Subject: Comments on VehicleInterface and Availability (Vadim's
>>>> proposal)
>>>>
>>>> The VehicleInterface section splits up the one interface into 3:
>>>>
>>>> VehicleInterface, that has get(),
>>>> VehicleConfigurationInterface, that is used to signify attributes that
>>>> will never change and cannot be set()
>>>> VehicleSignalInterface which has set() and subscribe().
>>>>
>>>> This generally looks good to me.
>>>>
>>>> The Availability section adds a couple granular availability methods
>>>> to VehicleInterface(s).  Question: Why do the methods have an
>>>> "DOMString attributeName" argument?  This might be a typo because in
>>>> the examples those are absent.
>>>>
>>>> The usage of "Retrieval" might be worded "Get" for consistency, but
>>>> this is probably a bikeshedding issue.
>>>>
>>>> It also adds a callback mechanism in case availability changes.  This
>>>> makes sense.  The only issue I could come up with is the naming of
>>>> "ChangedListener".  I wonder if we should change the name of
>>>> subscribe() to dataChangedListener() again for consistency purposes.
>>>> "ChangedListener" is probably a more common pattern in the w3c and
>>>> other APIs.
>>>>
>>>> -Kevron
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>
>


Received on Thursday, 12 June 2014 18:13:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:06:39 UTC