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

Thanks, Vadim.  I'll allocate some time to edit with your changes.

On Fri, Jun 27, 2014 at 8:46 AM, Vadim Draluk <vadim@draluk.net> wrote:
> Kevron,
>
> wasn't planning to do any formal editing, just to provide a separate version
> with proposed changes. If I have to do it, will rely on your guidance with
> logistics. Will likely not be able to get to it till mid-July
>
> Cheers
>
> Vadim
>
> ________________________________
> From: "Rees, Kevron" <kevron.m.rees@intel.com>
> To: "Abramski, Adam M" <adam.m.abramski@intel.com>
> Cc: Vadim Draluk <vadim@draluk.net>; "public-autowebplatform@w3.org"
> <public-autowebplatform@w3.org>; "internal-autowebplatform@w3.org"
> <internal-autowebplatform@w3.org>
> Sent: Friday, June 27, 2014 8:38 AM
>
> Subject: 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 16:02:17 UTC