Re: Feedback on Vehicle Web API style

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/
>
>

Received on Thursday, 2 January 2014 19:03:20 UTC