Re[2]: Feedback on Vehicle Web API style

Hi Kevron,

Thanks for your explanation.
I understand the concept of the "zone" very well.

Cheers,
Futomi


On Thu, 2 Jan 2014 11:02:51 -0800
"Rees, Kevron" <kevron.m.rees@intel.com> wrote:

> Thanks Futomi.  Those are some excellent comments.  More inline:
> 
> On Wed, Dec 25, 2013 at 8:57 PM, Futomi Hatano
> <futomi.hatano@newphoria.co.jp> wrote:
> > Hi all,
> >
> > I'm Futomi Hatano, a web developer, CTO, Newphoria Corporation.
> > I'm writing to this ML for the first time.
> > I'm interested in Vehicle Web API. I just join this BG.
> >
> > I have some feedbacks and questions on Vehicle Web API style.
> > https://github.com/tripzero/automotive-bg/blob/master/vehicle_spec.html
> >
> > -----------------------------------------------------------------
> > * DOMFuture Interface
> > -----------------------------------------------------------------
> >
> > I wonder if the DOMFuture interface is as same as the DOM Promise.
> > http://www.w3.org/TR/dom/#promises
> > If so, I think this section is needless in the spec,
> > and the WebIDL for VehicleInterface Interface should be tweaked as below.
> >
> > ---
> > [NoInterfaceObject]
> > interface VehicleInterface {
> >   Promise get (...);
> >   Promise set (...);
> >   ...
> > }
> > ---
> >
> > Some specs which adopt the DOM Promise are helpful.
> > http://www.w3.org/TR/webmidi/#requestmidiaccess
> > http://www.w3.org/TR/discovery-api/#requesting-networked-services
> >
> 
> You are correct.  DOMFuture is the same as Promise.  I had to define
> DOMFuture so respec wouldn't complain because DOMFuture is not an idl
> type.  I'll try with Promise.  Thanks.
> 
> > -----------------------------------------------------------------
> > * subscribe()/unsubscribe() methods in the VehicleInterface Interface
> > -----------------------------------------------------------------
> >
> > I think the interface should adopt the DOM Event model,
> > that is, addEventListener() and removeEventListener().
> > http://www.w3.org/TR/dom/#events
> >
> 
> addEventListener() has no concept of zone.
> 
> > The subscribe()/unsubscribe() approach is not able to handle multiple event types.
> > Let's assume that we will define the battery status interface, for example.
> > If we adopt the subscribe()/unsubscribe() approach,
> > app developers can get only an event for a change of charge level.
> > Some developers would want an event for a change of charging or not.
> > Some developers would want an event for a change of estimated remaining running distance.
> > When we accept these needs, how can we resolve?
> >
> 
> I think this can be handled, but it depends on how the data types are
> defined.  For example, if there is a type for BatteryChargeLevel the
> subsribe would work like this:
> 
> vehicle.batteryChargeLevel.subscribe(...);
> 
> But if it's a more complex object like BatteryType {  attribute short
> chargeLevel; ...} then you would access it like this:
> 
> vehicle.battery.subscribe( function (battery) { console.log("battery
> level: " + battery.chargeLevel); } );
> 
> > -----------------------------------------------------------------
> > * The zone attribute in the VehicleCommonDataType Interface
> > -----------------------------------------------------------------
> >
> > I don't think the zone attribute is appropriate as a "common" data type.
> > It is relevant to only climate control, seat belt status, as far as I can imagine.
> > The zone attribute is irrelevant to most of the interfaces which will be defined in the future.
> >
> 
> There are many data types that do need zone.  Anything that has to do
> with a passenger can have a zone (seat position, door locks, window
> locks, etc).  Tires can also be arranged in a zone pattern.  Basically
> anytime there is a data type that can occur in multiple physical
> locations inside the vehicle would or could have a "zone" attribute.
> 
> > If the zone attribute will be kept in the VehicleCommonDataType,
> > the description should be tweaked a little bit.
> > Currently, the spec says:
> > --
> > zone of type Zone, readonly
> >   must return zone for this data type or undefined if there is no zone associated with this data type
> > --
> > I think it should return null if there is no zone associated with this data type,
> > because "undefined" implies the UA doesn't implement the property (attribute).
> >
> > -----------------------------------------------------------------
> > * The time attribute in the VehicleCommonDataType Interface
> > -----------------------------------------------------------------
> >
> > The attribute name "time" is ambiguous to me.
> > It represents a time stamp when an event something had been fired, doesn't it?
> > If so, I prefer "timeStamp".
> > Besides, it should return DOMTimeStamp, not Date.
> > The Date is not specified in W3C, it means just an ECMAScript object.
> > Many other specs specified in W3C use "timeStamp" as a attribute name for time stamp,
> > and it returns DOMTimeStamp.
> >
> > For example,
> > http://www.w3.org/TR/dom/#event
> > http://www.w3.org/TR/geolocation-API/#position_interface
> >
> > The DOMTimeStamp interface is specfied in DOM3 Core.
> > http://www.w3.org/TR/DOM-Level-3-Core/core.html#Core-DOMTimeStamp
> >
> > Though the DOMTimeStamp and the Date is identical in ECMAScript for practical purposes,
> > W3C specs should be more versatile because W3C specs are not only for ECMAScript.
> >
> > interface VehicleCommonDataType {
> >     ...
> >     readonly    attribute DOMTimeStamp timeStamp;
> > };
> 
> I agree.  I will change it to timeStamp of type DOMTimeStamp.  Thanks!
> 
> >
> > -----------------------------------------------------------------
> >
> > Thanks for your time.
> >
> > Cheers,
> > Futomi
> >
> > --
> > Newphoria Corporation
> > Chief Technology Officer
> > Futomi Hatano
> > --
> > futomi.hatano@newphoria.co.jp
> > http://www.newphoria.co.jp/
> >
> >

--
Newphoria Corporation
Chief Technology Officer
Futomi Hatano
--
futomi.hatano@newphoria.co.jp
http://www.newphoria.co.jp/

Received on Sunday, 5 January 2014 03:23:02 UTC