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 22:53:40 UTC