Hi Kevron, Your first proposal below seems better to me too and my view is that it's acceptable to break the API given a 1.0 version has not been released yet. I would just clearly document this including when the API changed (and what to).
My 2 cents, Geoffroy From: [email protected] [mailto:[email protected]] On Behalf Of Rees, Kevron Sent: Tuesday, March 26, 2013 7:24 PM To: [email protected] Subject: [IVI] RFC: Proposed AMB DBus API change Hi all, Currently, each property within AMB has a corresponding time stamp that indicates when the property was received by the source. Internal plugins have access to the time data and the websocket protocol supports this as well, however, the DBus plugin does not. There are a couple ways we can change the DBus API to support this feature: 1) Each property shall return a struct {value, timestamp}. The benefit here is that there is an easy way to access both the value and the timestamp in a single DBus call. However, this will break the API and all users of the API will have to update their code. 2) Separate property for time stamp for each vehicle data property. For example: the DBus object for VehicleSpeed would have one additional property: VehicleSpeed VehicleSpeedTime The benefit to this is that there will be no breakage to the API and applications written to use the DBus API will work. The downside to this API is there is no guarantee that VehicleSpeedTime will be a 1:1 map to the VehicleSpeed property. For example, say an application requests VehicleSpeed, does some processing and then requests VehicleSpeedTime. VehicleSpeedTime may have changed since VehicleSpeed was requested and therefor will not be accurate. I'm thinking that solution 1 is the best option, but would like feedback on breaking the API. There is also the question on whether the internally supported "sequence" attribute is valuable to applications. If it is valuable to applications, It's support in the DBus API would require similar changes outlined above. For example: option 1: {value, timestamp, sequence} option 2: VehicleSpeed, VehicleSpeedTime, VehicleSpeedSequence Thanks, Kevron Intel Corporation NV/SA Kings Square, Veldkant 31 2550 Kontich RPM (Bruxelles) 0415.497.718. Citibank, Brussels, account 570/1031255/09 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ IVI mailing list [email protected] https://lists.tizen.org/listinfo/ivi
