On 09/15/2010 10:24 AM, [email protected] wrote:
I _currently_ see this quite differently. The attached picture explains my
views. Applied to this case, GeoClue defines the platform / core OS level APIs
and would need to be supported in any MeeGo compliant device that supports
location services. The Qt Mobility API back-end would be written on top of
GeoClue APIs.
The other way (that Michael is proposing) to handle this is that Qt Mobility
APIs effectively become full members of the MeeGo core OS. So SW components in
the core OS level would also use Qt Mobility APIs to access location services
if they need them. And GeoClue would become something that vendors could use in
their devices if they wish (would be fully optional).
But if we move in this direction, then e.g. the Sensor Framework vs. Qt
Mobility sensor APIs question is analogous to this (and I guess there are other
examples as well).
I think that this is a pretty important generic architectural question in MeeGo
OS and would appreciate guidance from Arjan and other MeeGo architects.
Technically both options can be made to work. The main difference is in what
kind of dependencies we create into MeeGo OS.
Regards, Jari
backend
Hello,
How about "standardizing" the feature-sets and document well the current
cross-dependencies rather than fix the projects providing the stuff
currently. The ongoing way feels fine as a just another concept to
provide a bit more properly defined applications API. But I sense many
of us would like to see the Meego as more flexible and open to future
devices of any kind.
I could consider e.g. graphics and multimedia as an analogous example to
this. Khronos APIs reached Qt native implementations years ago and now
we have that for fixed certain graphics stacks. Its similarly just
because it happened to evolve like this. How about allowing &
advertising that OpenVG efforts are welcome to use Meego as playground
as well. I feel also that OpenMAX AL could head up as Meego multimedia
middleware. Do we have followers to comment on "closer to Khronos
ideology" in general ?
Such openness would reach aplenty of talented engineers to contribute
along with manufacturer's derived products. They break the stacks
anyway, so why not politely try to take it into control of the community ?
I realize that with such visionaries Meego wouldn't be as far as it is,
but in my opinion its more a matter of appearance with compliance
specifications and less affective to current roadmap with reference
devices middleware.
regards,
-Teemu
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
