On Sep 14, 2010, at 10:22 AM, Alexey Khoroshilov wrote:
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?
That's consistent with my thinking.
"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?
In my view, a MeeGo compliant app should be provided in a single package with
no external dependencies that are not satisfied by a MeeGo compliant device.
Allowing applications to have arbitrary external dependencies that are resolved
at install time adds a great deal of complexity and uncertainty for a device
manufacturer (substitute "MeeGo software stack provider" for "device
manufacturer" if you wish).
I want to create a simple "contract" between the device manufacturer and the
application developer: the device manufacturer promises to provide a defined
set of packages and the application promises to install and run correctly using
only those packages.
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.
I'm in favor of this approach.
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
<ATT00001..txt>
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
