Em Quarta-feira 19 Maio 2010, às 12:40:12, Cornelius Hald escreveu: > However, if we want to have the high goal that Quim described, I don´t > see how we can allow API extension at all. > > "Going back to the original point, what really matters is that MeeGo > users can enjoy the combination of MeeGo devices and applications of > their choice no matter what choices have been made by the developers of > those devices and applications." > > The important part is "[...] no matter what choices have been made by > the developers of those devices and applications."
I think the interesting point to take out of this is to understand why there
are extra libraries and APIs in the first place.
I can think of a couple of cases:
1) differentiation, such as vendor-specific APIs
As the name says, those are vendor-specific. The vendor is, of course, allowed
to use those APIs for themselves. I'd expect this to include minor
functionality or just extensions that applications don't really need in order
to survive. Vendor-specific APIs are good for the vendors to share code between
their apps.
2) experimental
In this case, I think developers should be the ones to understand what they're
getting themselves into when they use experimental APIs.
3) fulfilling a need
In this case, it's a full productised library that exists because the MeeGo
API doesn't fulfil a particular need/use-case. Those cases should be analysed
and the MeeGo API should be extended to cover those cases, if necessary. This
could happen by blessing the extension library and moving it to the "MeeGo
API" umbrella when it meets MeeGo's own QA requirements.
4) alternative libraries
I'm not sure these can be considered "extension libraries", but for the
purposes of compliance, we have to keep them in mind.
In all cases, I think it's important that we keep an eye on what kinds of
extensions are being deployed and why. We should strive to keep them to a
minimum so as to ensure maximum compatibility between categories, verticals
and devices.
I'm particularly concerned about the first case (differentiation libraries),
because their clear goal is to say "my device is better".
What steps we may take to discourage them, like the "MeeGo compliant" sticker
and checkers, like the LSB checker, I don't know.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
