MeeGo-ivi Digest, Vol 13, Issue 11

[Simon Bolek]

Date: Wed, 28 Sep 2011 14:48:44 -0700

Subject: Re: [MeeGo-ivi] [MeeGo-IVI] What does Tizen means for
MeeGo-IVI?
Content-Type: text/plain; charset="iso-8859-1"
MeeGo IVI's work has always been focused on the middleware on top of the
Linux stack provided by MeeGo Core to support the functionality required
for
vehicle applications such as connectivity to vehicle networks (CAN, MOST,
etc), audio management, etc. The user experience has been provided as an
example and is expected to be replaced for a customized one providing
differentiation.
In that sense all the work that has been done for IVI in conjunction with
MeeGo still applies to Tizen. As the matter of fact, for MeeGo 1.3 the team
has greatly improved MeeGo IVI so that it can run on a wider variety of
hardware and to make it simpler to remove the demo UX and replace it with
something more functional.

I fully agree with both above statements. Current IVI UX has just been
implemented as a reference one, no questions at all...

HTML5 is mainly an abstraction layer for application development. The
native
application approach chosen for MeeGo puts pretty strong constraints on how
APIs can evolve after products have been shipped. An API defines a contract
between the application and the underlying system and if one changes
without
the other then there is trouble ahead. An abstraction layer such as HTML5
provides the necessary flexibility for evolution without breaking things.
It
also provides an abstraction from the underlying hardware and its
architecture. The idea is obviously not new and if you remember the early
days of Java this was exactly what Java was intended to do: provide an
abstraction layer for embedded software applications.
:rjs

...however, a part of meego core is also Qt, Qt Mobility and Qt WRT, see

http://wiki.meego.com/In-vehicle/Roadmap/API
https://meego.com/developers/meego-architecture/meego-architecture-layer-view

and in IVI community apart of defining abstract apis for IVI,
we were making extensions for Qt APIs mentioned.

So from IMHO not continuing supporting these Qt APIs, but only starting with
HTML5 would be a great step back the roots.

cheers
simon:)
mit freundlichem Gruss / best regards / pozdrawiam / atentamente
Simon P. Bolek
------------------------------------------------------
Dipl. Inf. Simon P. Bolek
SAP Consultant
Business Mobile and IVI Solutions
Cell: [phone]
mailto: simon.bolek-B9s5scSTfCld/oRx+***@public.gmane.org
http://www.arcom-ivi.de/
XING: https://www.xing.com/profile/SimonP_Bolek
GULP: 84465

[Rudolf Streif]

Post by Simon Bolek
...however, a part of meego core is also Qt, Qt Mobility and Qt WRT, see
http://wiki.meego.com/In-vehicle/Roadmap/API
https://meego.com/developers/meego-architecture/meego-architecture-layer-view
and in IVI community apart of defining abstract apis for IVI,
we were making extensions for Qt APIs mentioned.
So from IMHO not continuing supporting these Qt APIs, but only starting
with HTML5 would be a great step back the roots.

Native APIs will never go away and having said that the work that was
started by extending Qt APIs for sensors, automotive etc. will continue.
Even if you imagine defining an HTML5 object called vehicle to access
vehicle information in the form of

<script type="text/javascript">
if (vehicle.speed > 250) {
document.write("You are burning rubber!);
}
</script>

you will eventually use a native API to implement that functionality in your
web runtime. And of course that API could also be used for native UX.
However, for an application developer who would like to be able to sell his
work to as many drivers/passengers riding in many different cars the HTML5
approach would be beneficial. Of course, the automotive industry would have
to agree on a standard for that to work.

:rjs