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: Wed, 11 Jun 2014 23:15:19 +0000
To: "Rees, Kevron M" <kevron.m.rees@intel.com>, Vadim Draluk <vadim@draluk.net>, "public-autowebplatform@w3.org" <public-autowebplatform@w3.org>
CC: "internal-autowebplatform@w3.org" <internal-autowebplatform@w3.org>
Message-ID: <6AB32C125D193D47AE66073666ED3B5E34B0E2AA@ORSMSX105.amr.corp.intel.com>
He should automatically be subscribed to the public list when he became a member of the group it automatically adds the member to *BOTH* internal and public mailing lists...not sure why his emails are bouncing when he sends it to public but we could always as the W3C infrastructure folks to help if need be.  
Adam

-----Original Message-----
From: Rees, Kevron [mailto:kevron.m.rees@intel.com] 
Sent: Wednesday, June 11, 2014 3:53 PM
To: Vadim Draluk; public-autowebplatform@w3.org
Cc: internal-autowebplatform@w3.org
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> 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> 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>
>>
>> To: Vadim Draluk <vadim@draluk.net>
>> Cc: "internal-autowebplatform@w3.org" 
>> <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> wrote:
>>> Resending my response as my message to the public list bounced, as 
>>> usual
>>>
>>> ----- Forwarded Message -----
>>> From: Vadim Draluk <vadim@draluk.net>
>>> To: "Rees, Kevron" <kevron.m.rees@intel.com>; 
>>> "public-autowebplatform@w3.org" <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>
>>> To: "public-autowebplatform@w3.org" <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 Wednesday, 11 June 2014 23:15:55 UTC

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