W3C home > Mailing lists > Public > public-autowebplatform@w3.org > April 2014

Re: GetHistory API RFC

From: <andy@cx3marketing.com>
Date: Wed, 9 Apr 2014 16:06:25 -0400
Cc: "public-autowebplatform@w3.org" <public-autowebplatform@w3.org>
Message-Id: <EBEC8D9E-5224-4EB1-8FB8-3DFF4D68FCC2@cx3marketing.com>
To: "Rees, Kevron" <kevron.m.rees@intel.com>
While I’m on a roll :-) ...

I don’t disagree with the value of having history—it can be very useful, especially if there’s a consistent way to provide access to it. 

My concern with GetHistory was always that it assumes the system is logging *everything*. That’s an unreasonable load, IMHO, especially since some CAN parameters will require an active request, potentially leading to an implementation flooding the CAN bus to acquire data that may never be used.

What about if the application informs the system layer which bits of history it cares about? The assumption can be that no data will be logged unless you call something like <myclass>.enableHistory() first. And of course you can later .disableHistory(). This addresses the concern of overloading the embedded system and CAN bus with collecting unneeded data.


Andy Gryc | Co-founder
M: +1 613.618.8730 | E: andy@cx3marketing.com
W: www.cx3marketing.com

On Apr 9, 2014, at 3:52 PM, Rees, Kevron <kevron.m.rees@intel.com> wrote:

> The purpose of GetHistory is to allow application to get stored
> information from the system without having to perform logging
> themselves.  Having the system provide data logging avoids the problem
> of having multiple applications logging the same data.
> Being able to retrieve logged data allows for some interesting
> features.  There are a number of projects that log and do neat things
> with vehicle data[1].
> This API will come with the assumption that the system will determine
> what data is stored, how often and how far back in time data will be
> available.
> This API may have one flaw however in that it may be processor
> intensive to do huge queries and pass that data to web applications.
> If we want to avoid that, we may want change the API with that in
> mind.
> It is also possible we can offer this API as an appendix to our
> vehicle data specification.
> [1] - http://icculus.org/obdgpslogger/
> interface HistoryItem {
>  readonly attribute any value;
>  readonly attribute DOMTimeStamp timeStamp;
> }
> callback GetHistoryCallback = void callback(HistoryItem[] items);
> partial interface VehicleInterface {
>  Promise getHistory(Date begin, Date end, optional Zone zone);
>  readonly attribute boolean isLogged;
>  readonly attribute Date from;
>  readonly attribute Date to;
>  readonly attribute short rate; // µHz
> }
> //check if there is data being logged for vehicleSpeed:
> if(vehicle.vehicleSpeed.isLogged)
> {
>   /// get all vehicleSpeed from the beginning of time
>   vehicle.vehicleSpeed.getHistory(new Date(0), new Date).then(
> function ( data ) {
>    console.log(data.length);
>  });
>  /// get all vehicleSpeed since it was first logged:
>  vehicle.vehicleSpeed.getHistory(vehicle.vehicleSpeed.from,
> vehicle.vehicleSpeed.to).then( function ( data ) {
>    console.log(data.length);
>  });
> }
> -Kevron
Received on Wednesday, 9 April 2014 20:06:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:52:52 UTC