Hello Josef, I'm also interested in the definition of an in-vehicle API. Before defining the details of such an API, I'd be interested in discussing a more high-level classification.
First, we should define who would be the API users? I believe the definition of the API will fall into multiple categories depending on who would use it. For example : - car manufacturer & Tier-1 suppliers who would be able to access/write critical information (e.g. for diagnostic / information collection purposes), - affiliated developers (e.g. the ones providing applications shipped with the head-unit, which would need raw information such as the ones for GPS dead reckoning), - "any" developper (which may need already processed information). Some of the API might not be available to all of the actors, or read/write access may be different for each of them. That being said, access control would be an important part of the system. I'm not sure yet how that could be achieved but it must be kept in mind when designing the overall architecture. Any comments? Thank you, -- Romain KUNTZ Toyota InfoTechnology Center [email protected] On Jul 26, 2011, at 15:02, Josef Raschen wrote: > Hi, > > I tried to work on the car-systems function-list: > https://spreadsheets.google.com/spreadsheet/ccc?key=0AumR8Pg5Sy05dEpBRTlvZ0VuWTh4V05NNTRHWXBIWXc&hl=en_US > > This is based on the version from the wiki with some new functions and some > regrouping. I also changed the personalization settings. I think we should > differentiate between a saved state of a system (connected with the id of the > key) and the set/get functions of the systems. > > Josef > _______________________________________________ > MeeGo-ivi mailing list > [email protected] > http://lists.meego.com/listinfo/meego-ivi _______________________________________________ MeeGo-ivi mailing list [email protected] http://lists.meego.com/listinfo/meego-ivi
