[vehicle-spec] subscribe() is implementation dependant about automotive HOT 21 CLOSED

Just realized that for some signals the above suggestion might be a bit risky. If the developer omits the period for a signal that is constantly updating we might run into performance issues...but then again without it the devloper has no means of control,

from automotive.

Then maybe it should not be optional to add a period. -> sunscribe(period), period is ms.

from automotive.

Peter-san,

This is Shinjiro Urata from ACCESS.
Thanks for raising this issue as my colleagues and I are thinking similar things.

1.As you wrote,

Ex1:
subscribing to the vehicle speed : subscribe(100)
// "real time" change, frequent
Ex2:
subscribing to the left door being open/closed: subscribe() 
// event driven change, not so frequent

I agree that vehicle speed should be Ex1 and door shoud be Ex2.

2.Regarding the previous comment

Then maybe it should not be optional to add a period. -> sunscribe(period), period is ms.

for door, transmission and other not so frequent changing value,
for me, I'd like to use "event driven" style.

It is possible to simulate "event driven" style with Ex1 style by JavaScript by just ignoring
when value is not changed, but in that case, JavaScript program have to handle
too many callback call and may not possible to handle callback in time when subscibing many interfaces.
(I mean to-be-called callback functions may pile up in a queue.)

To keep JavaScript program light, I think it's better to reduce number of callback call,
and so, better to have "event driven" style, I think.

3.To subscribe inerfaces of continuous value with "event driven" style, below style might be useful.

EX. 3
subscribing to the fuel level : subscribe("value", 5)  // not sure about interface
// event driven with unit value

This means, getting event when fule level changed by 5%.

from automotive.

I like the idea of it being optional. Hopefully the system has some sane
defaults -otherwise it probably is going to have performance problems
elsewhere in the system.

On Thu, May 28, 2015 at 6:36 AM, Shinjiro Urata [email protected]
wrote:

Peter-san,

This is Shinjiro Urata from ACCESS.
Thanks for raising this issue as my colleagues and I are thinking similar
things.

1.As you wrote,

Ex1:
subscribing to the vehicle speed : subscribe(100)
// "real time" change, frequent
Ex2:
subscribing to the left door being open/closed: subscribe()
// event driven change, not so frequent

I agree that vehicle speed should be Ex1 and door shoud be Ex2.

2.Regarding the previous comment

Then maybe it should not be optional to add a period. -> sunscribe(period), period is ms.

for door, transmission and other not so frequent changing value,
for me, I'd like to use "event driven" style.

It is possible to simulate "event driven" style with Ex1 style by
JavaScript by just ignoring
when value is not changed, but in that case, JavaScript program have to
handle
too many callback call and may not possible to handle callback in time
when subscibing many interfaces.
(I mean to-be-called callback functions may pile up in a queue.)

To keep JavaScript program light, I think it's better to reduce number of
callback call,
and so, better to have "event driven" style, I think.

3.To subscribe inerfaces of continuous value with "event driven" style,
below style might be useful.

EX. 3
subscribing to the fuel level : subscribe("value", 5) // not sure about interface
// event driven with unit value

This means, getting event when fule level changed by 5%.

—
Reply to this email directly or view it on GitHub
#29 (comment).

from automotive.

If you look at the sensor APIs on Android, many of them (as suggested here) require a frequency in ms. Depending on the API, the parameter means "receive this data at most every n milliseconds." In reality, the frequency is advisory.

from automotive.

Sorry if this come out too harsh but in what way are callbacks not event driven? Isn't that an implementation detail?

I also don't think that callbacks make the JS too heavy. An Event Emitter can simplify this.

Regarding subscriptions, I think that callbacks should be the preferred mechanism. If you look at the Observer pattern, an callback is used for subscribe. However, when you want to retrieve a single value asynchronously, a promise is preferred. (I actually think that ES6 generators are even better than promises but that may be a bit early).

from automotive.

Hi Kevron-san

I like the idea of it being optional.

This is good to me, too. I'd like to keep simple usage.

from automotive.

Hi Dave-san

Sorry if this come out too harsh but in what way are callbacks not event driven?

Excuse me that my expression was not clear.
Of course callback functions are invoked by some event and what I concern is what should be treated as event inside Vehicle API implementation.

var vehicle = navigator.vehicle;
vehicle.vehicleSpeed.subscribe(cb(){});  // cb() called when `speed` changed by xx m/h or every xx ms

vehicle.door.subscribe(cb(){}); //  cb() called when door `status` or `lock` changed.

vehicle.steeringWheel.subscribe(cb(){});  // cb() called when `angle` changed by xx degree

These xx m/h, xx ms, xx degree can be implementation dependent.
But I wondered whether enough with implementation dependent or it should be configurable and would like to know everyone's opinion.
Anyway, use implementation dependent as default and configurable as optional is good to me.

I also don't think that callbacks make the JS too heavy. An Event Emitter can simplify this.

What I thought is something like this.

• I want to display many vehicle status in my JS application such as vehiclespeed, enginespeed, steeringwheel, acceleration, gyro, door status, temperature, many other things.
• Use subscribe() for all those interface.
• If 20 or 30 or more interfaces's callbacks are invoked by every xx ms, this might become heavy task for JS application in some case.

Of course this depend on hardware spec, JIT, vehicle API implementation's architecture, what is done inside callback functions.
But to think about that JS application have to do many other things such as user operation handling, UI animation, network communcation(AJAX, websocket, etc), etc, I though too many invoke of callback might cause performance trouble in some poor environment.
And so, I thought make

sunscribe(period), period is ms.

style mandatory might be dangerous.

An Event Emitter can simplify this.

If you mean by this is vehicle API implementation can cut off unnecessary callback invocation (such as skipping vehicle speed callback if speed change is less than 1 m/h), I agree that implementation can reduce JS application's load by this way and should do it.

Regarding subscriptions, I think that callbacks should be the preferred mechanism. If you look at the Observer pattern, an callback is used for subscribe. However, when you want to retrieve a single value asynchronously, a promise is preferred. (I actually think that ES6 generators are even better than promises but that may be a bit early).

I agree on this part.

from automotive.

@aShinjiroUrata Okay, I think we agree on most points. Being able to specify the period is important.

period would be where the event is emitted at most once per n ms, based on changes. If n is 100, then an event would trigger every 100 ms or greater.

What happens if you want the status every 1 second, regardless of changes?

from automotive.

@aShinjiroUrata Okay, I think we agree on most points. Being able to specify the period is important.

Yes.

period would be where the event is emitted at most once per n ms, based on changes.
If n is 100, then an event would trigger every 100 ms or greater.

This is combination of period and change, isn't it?
What I was thinking was period only and change only method.

What happens if you want the status every 1 second, regardless of changes?

This is possible by period only method.
However, period only method has bad point, which is notification keep coming even when value is not changed. (e.g. vehicleSpeed keep notified even when car is not moving. It is useless notification.)

In this view point, combination of period and change looks better.

Maybe we should classify value type and needs for notification as Peter-san did in the beginning.
From practical point of view, I think

• discrete value signal (door status, transmission status, airbag detnation) should be notified immediately and period setting does not suit.
• not frequently changing continuous value(external/internal temperature, brake.padWear, brake.fuidLevel) should be notified when value changed for certain degree.
• frequently changing continuous value (vehicleSpeed, steeringWheel) should be notified by combination of period and value change.

from automotive.

Hi, Sorry for being absent from the discussion/issue. I basically agree with:

• discrete value signal (door status, transmission status, airbag detnation) should be notified immediately and period setting does not suit.
• not frequently changing continuous value(external/internal temperature, brake.padWear, brake.fuidLevel) should be notified when value changed for certain degree.
• frequently changing continuous value (vehicleSpeed, steeringWheel) should be notified by combination of period and value change.

Maybe , though, we should consider if we actually need to have a notification when a value is changed by a certain degree ? I think it would be useful, but it should be weighed against API complexity.

from automotive.

Maybe , though, we should consider if we actually need to have a notification when a value is
changed by a certain degree ? I think it would be useful, but it should be weighed against API
complexity.

I also concern about API complexity.
It's ok to me to ignore notification by certain degree of value change until someone will claim it necessary in the future.

In that case, temperature, brake.padWear etc. will be triggered by implementation dependent timing.
If the timing is too coarse, application programmer don't have way to configure it. but if implementation dependent timing is reasonably fine, it will be ok in most case.

from automotive.

In that case, temperature, brake.padWear etc. will be triggered by implementation dependent timing.
If the timing is too coarse, application programmer don't have way to configure it. but if >implementation dependent timing is reasonably fine, it will be ok in most case.

Agree.

from automotive.

So, is the conclusion to add subscribe(period n) to the API. Where n is defined as: deliver the data at most n milliseconds ?

Thus, we would have:

1. subscribe(period n) , data delivered at most n ms.
2. subcscribe(), implementation depending on actual data.

from automotive.

So, is the conclusion to add subscribe(period n) to the API.
Where n is defined as: deliver the data at most n milliseconds ?

OK to me.

Even if I want to subscribe with long interval such as 1 hour, it is like subscirbe(3600000) and no big problem.

By at most I understand, callback will be invoked by every n msec in most frequent case, and if the value is not changing the implementation don't have to call the callback.
And, how much delta of value can cause the callback invoke is implementation dependent as we discussed.

Thus, we would have:

1. subscribe(period n) , data delivered at most n ms.
2. subcscribe(), implementation depending on actual data.

Actually it will be like

subscribe(callback, zone, period);

from automotive.

Should we merge this with #37, if fact then close this one and continue with #37 ? I am not sure what the outcome of 37 is . If we should keep the current API strategy then I guess we should not merge ? and the add the following with pull request and instead close #37:

subscribe(callback, zone, period)

from automotive.

Personally I think, adding period is not so big change and I suppose no need to wait for #37 conclusion.
If #37 results in a big change, adding period might become meaningless, but I guess it is OK in that case.

from automotive.

If ok, I would create pull request with below change.

[NoInterfaceObject]
interface VehicleSignalInterface : VehicleInterface {
    Promise        set (object value, optional Zone zone);
    unsigned short subscribe (VehicleInterfaceCallback callback, optional Zone zone, optional unsigned long period);  // added here
    void           unsubscribe (unsigned short handle);
};

and

13.1 Methods
....
MUST return handle to subscription or 0 if error. If 'period' is specified, 'callback' MUST be invoked at most once per 'period' milliseconds.

from automotive.

Of course! Perfect !!
/pw

Fr�n: Shinjiro Urata [[email protected]]
Skickat: den 9 juli 2015 13:44
Till: w3c/automotive
Cc: Peter Winzell
�mne: Re: [automotive] [vehicle-spec] subscribe() is implementation dependant (#29)

If ok, I would create pull request with below change.

[NoInterfaceObject]
interface VehicleSignalInterface : VehicleInterface {
Promise set (object value, optional Zone zone);
unsigned short subscribe (VehicleInterfaceCallback callback, optional Zone zone, optional unsigned long period); // added here
void unsubscribe (unsigned short handle);
};

and

13.1 Methods
....
MUST return handle to subscription or 0 if error. If 'period' is specified, 'callback' MUST be invoked at most once per 'period' milliseconds.

�
Reply to this email directly or view it on GitHubhttps://github.com//issues/29#issuecomment-119924233.

from automotive.

OK!
I made the pull request.

from automotive.

Note that if you're planning to poll sensors at a given interval, you might want to sync with the Generic Sensor API (which uses frequency in Hz).

You might also want to use a dictionary to allow for future extensibility.

from automotive.