On Wed, Aug 3, 2011 at 2:10 PM, Jussi Vänskä <[email protected]>wrote:
> On 08/03/2011 03:30 AM, Romain KUNTZ wrote: > >> >> [ . . . ] > 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? >> > > I would go with this type of API segments divided according to the level > and ease of access: > > for all developers: > - QtQuick signals and data models. > So developers would only have access to "data models" and Qt Signals? Not the actual data structures themselves? This would seem to preclude talking to things like Diagnostic Log and Trace. Or the compositor. Or systemd, should that be used. > > for tier 1 developers > - Qt API > This excludes ECU to ECU communication. Tier 1's would likely never accept this. > > for system developers / vendors > - dbus signal API > There are some questions about the viability of dbus in the automotive environment due to the fact that it is considered slow in comparison to other embedded IPC systems. > This would also nicely handle the security issue as the dbus is already a > system bus with established session control and safety features. > Customisation is also possible from QML all the way down to the dbus for > those who absolutely need it through the Qt dbus interface. SocketCAN which > was discussed earlier could be revealed as a dbus object as could be done > with any other additional vehicle bus. > This would likely be extremely limiting and would hardly be sufficient for the automotive environment. A car is not a phone. Regards, Jeremiah
_______________________________________________ MeeGo-ivi mailing list [email protected] http://lists.meego.com/listinfo/meego-ivi
