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

Vadim,

Will you be making a pull request on github with your recommendations?
 I'm just wondering if I need to be looking for the pull request or if
I need to allocate some time to manually merge in your proposal.

Thanks,
Kevron

On Thu, Jun 12, 2014 at 11:12 AM, Abramski, Adam M
<adam.m.abramski@intel.com> wrote:
> 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 Friday, 27 June 2014 15:38:35 UTC