Thiago Macieira wrote:
Em Quarta-feira 19 Maio 2010, às 11:34:58, Cornelius Hald escreveu:
Example:
We have the reference Meego Handset UX and Nokia decides to customize
it. They exchange the theme, graphics etc., which shouldn´t be a
problem. But they also add the NokiaFancyButton API. This button is
based on Qt and provides some über cool animations and stuff. Are they
allowed to do so?
If yes, each application, that makes use of NokiaFancyButton API will no
longer be compatible with other Meego Handset products. So how will
compatibility be ensured?
Adding new libraries is ok. I expect that to happen all the time.
I also expect it, but it might not be only one library, but an entire UI
framework. Now an application coded explicitly towards this new UI
framework is surely not a Meego-Application. Or is it?
What developers need to understand is that those libraries are not part of the
MeeGo API. If they choose to use them, they will be subjecting themselves to
whatever binary guarantees and release schedules those libraries provide, as
well as being deployed only on certain devices.
I don't think this is a compliance issue. It's a communication issue.
I think compliance can help with communication. Lets say there is a tool
that checks my newly written application for usage of non-standard API
and it finds that in fact I´m using non-standard API. Then, I think, my
application shouldn´t get the "Meego Compatible Sticker", should get
flagged differently in an app store, etc.
We do not only have to communicate to developers to be careful about
non-standard API, but we also have to communicate to our end users. They
must exactly understand what they can expect from each device and each
3rd party application.
And I think the SDK should not include by default those extension APIs. But it
should be possible to add them later, *consciously*. ("I know what I'm doing,
please install this library")
That would be the communication towards the developers and is surely a
good thing.
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."
Cheers!
Conny
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
