On 09/13/2010 11:53 PM, Quim Gil wrote:
On 09/13/2010 12:04 PM, ext Alexey Khoroshilov wrote:
- Should MeeGo Extras packages be compliant themselves?
Define "compliant" in this context, please. :)
In this context I meant "a MeeGo compliant library is a library which
uses only MeeGo core APIs or other compliant libraries" as it was
defined by Dave Neary in a parallel thread.
- Should we have several grades of MeeGo compliance applications? And
what is a purpose of the "MeeGo compliant application" concept?
For clarity, I would restrict the word "compliance" to the official
MeeGo compliance based on the official API.
Just to clarify, there are at least three kinds of API from MeeGo
compliance perspective (let's leave UX profiles out of the consideration
for now):
*MeeGo API* -- the set of programming interfaces defined as having the
highest level of compatibility promise, compatibility across an entire
major version of MeeGo. It includes Qt and libmeegotouch (Web Runtime
and Qt Mobility are in a wait list).
*Platform API* -- the complete set of programming interfaces defined for
MeeGo Core. The compatibility promise for those interfaces beyond the
MeeGo API is limited to the current version (major.minor) of the
operating system. It includes all API that MUST be installed by default
in any MeeGo compliant device.
*Other API* -- any other API that may either be or not be available on a
MeeGo device.
The compliance specification strongly encourages developers to use MeeGo
API only. So it is a really official API.
But if it is not enough, the specification allows to use Platform API
that has lower level of compatibility promise. In particular the
developer should be ready to incompatible changes/complete removal of
that API in the next minor version of the MeeGo.
I guess you meant that an application using only MeeGo API is compliant
as well as an application using Platform API is compliant. The
difference is in forward compatibility promise. Right?
"A MeeGo compliant app runs
on any MeeGo compliant device". If we dilute this we are opening a
Pandora's box.
That is a good definition. But what is about installation time issues?
We still have no clear agreement should MeeGo compliant applications be
allowed to be separated to several packages or not. If yes, the next
question is should MeeGo compliance specification say anything about
dependencies resolution process or should it be left out of scope?
The MeeGo Extras stable repository would contain apps tested to work on
top of official MeeGo releases. No "compliance" word needed: they are
"extras".
From compliance perspective, the question I concern myself with is:
What should we recommend to an application developer who would like to
use, for example, a python module that is not a part of the Platform
API. In this thread there were proposed the following non-mutually
exclusive recommendations so far:
1. You can consider the module as a part of your application. In this
case you have to add it to your RPM package, install to application
specific location, update it along with the application, etc.
2. You can extract the module to a separate package and make your
application dependent on that package. In this case,
2a. you can keep the module in your private namespace. Then you have
to install it to your private location and update it yourself. You can
share the module with other applications as you wish.
2b. you can share the module using the MeeGo Extras. In this case it
will be installed to public locations (like /usr/lib/python), but you
should be aware of the following risks:
- MeeGo Extras version can be overwritten by a vendor specific
package on some devices (hopefully it will be compatible with Extras' one);
- MeeGo project does not provide any guarantee regarding stability
and QA of MeeGo Extras packages further to MeeGo Extras community efforts;
- you have to follow changes in MeeGo Extras and test/update your
app appropriately.
Any thought?
Alexey Khoroshilov,
ISPRAS / Linux Foundation
_______________________________________________
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
