On 09/11/2010 01:00 AM, Quim Gil wrote:
Interesting discussion. Thank you!
On 09/08/2010 09:28 PM, ext Arjan van de Ven wrote:
I think there's a more general "what is MeeGo" thing behind this.
Yes. Let's agree first in the concept and then sorting out the technical
aspects will be easier.
For some, MeeGo is *the* distribution, there is only one, and because of
that, things that add to one will add to all of MeeGo
For others, MeeGo is "the reference", where the assumption is that many
companies will make variants that they all want to call "MeeGo", but
that are all different in some ways.
Here we are talking about libraries and apps. The backbone is the MeeGo
official API, provided by the MeeGo Core. I guess we all agree that no
matter how many variants companies and communities do around MeeGo that
official API needs to be there as a minimum requirement.
Well, this is a starting point.
Let's look first at MeeGo Extras:
If the developers targeting MeeGo Extras want to support libraries not
present in the MeeGo architecture then they should be able to do so, as
long as their packages work on top of MeeGo Core. And this should allow
developers targeting MeeGo Extras to use those libraries.
The MeeGo Community OBS and the MeeGo Extras QA process should help
porting, developing and maintaining these libraries and apps not sitting
directly on top of the official MeeGo API, but functional in a stock
MeeGo OS. The open development of MeeGo allows the maintainers of this
Extras components to test them against new releases and fix/negotiate in
case of breakage. In practice, this Extras maintainers are some of the
earliest and best testers of the unstable platform.
Now, what about the MeeGo vendors?
Those vendors sticking to the pure MeeGo stack with only some UX
customization on top can benefit directly from MeeGo Extras - or their
users can if they wish and their system is open enough to add the Extras
repo. If they are not interested, no problem.
Those vendors adding their own libraries on top of pure MeeGo can solve
the problem of collisions with MeeGo Extras by assigning a top priority
to their repos (I guess) or taking more drastic measures promoting their
own packages and basta. Or just like the MeeGo maintainers, they can
fix/negotiate with the Extras maintainers.
Those vendors doing deeper changes in the fringe of MeeGo compatibility
know anyway that they are playing with fire. If they want to get the
benefit of Extras they will need to do some homework. If they just want
a closed system without Extras input then there is no problem to solve.
In any case if there is a conflict the guidance comes automatically from
the MeeGo API and the MeeGo Core. The open development and the explicit
willingness to sit on top of newest releases as soon as they are ready
for production just makes the conflict resolution easier.
The first model is what Maemo used to be, there was only one Maemo; the
second model is what Moblin used to be, with many variants.
I think there is a way to benefit from the beautiful aspects of both
platforms. The versatile architecture of Moblin (compared to Maemo) was
beautiful. The proliferation of application developers and community
libraries (compared to Moblin) was beautiful too.
Frankly, I see MeeGo only be able to follow the second model; there is
more than one company doing products with MeeGo (heck, Novell already
has a variant), and thus there will be variants.
The moment you have variants, where you allow the variants to add their
own stuff on top, you can't have an "Extras" repository that works for
all of these variants anymore, only one that works
for the reference.
But we can't stop Extras because of the variants. On the contrary, a
strong and useful Extras will only help those variants to differ from
the MeeGo reference only when there is a good business reason to do so.
Any step you do out of the MeeGo way might cost you hundreds of apps not
available to your users.
Lat but not least: since the MeeGo launch and even before "open source
innovation" has been a driver of this 'joint platform developed under
the auspices of the Linux Foundation'. Limiting the MeeGo umbrella to
the official stack and API and limiting that innovation to companies
able to create their own ecosystems is imho limiting the MeeGo potential
too much. And for no good reason?
And once that's the case..... you really can't say "oh but you can
depend on anything that's in Extras". Or even "you can depend on things
that are not in the required set" to be honest.
I agree: the MeeGo project should put the emphasis on the official MeeGo
API as the only reliable dependency. This doesn't mean that we must cut
the Extras initiative pushing them out of the MeeGo umbrella.
It sounds reasonable to me. Keeping all non-Core dependencies within
each application package would be the best and the most clean technical
solution of many issues, but it has some drawbacks (as it was discussed
in the thread):
- potential conflicts of single instance services;
- wasted disk space that is essential for some devices;
- extra security risks in view of the fact that all instances should be
updated by all providers independently;
- lack of tool support that is required to make the approach easy-to-use
for application developers.
At the same time, the MeeGo Extras way leads to some concerns as well:
- How to guarantee acceptable quality and ABI stability of shared
packages from MeeGo Extras? Is it enough to just explain to application
developer consequences of her/his choice?
- Should MeeGo Extras packages be compliant themselves?
- Should we impose MeeGo Extras package naming scheme to MeeGo vendors
and vice versa? (Otherwise, different names of the same package may lead
to issues with simultaneous installation of applications depending on
that packages)
- Should we have several grades of MeeGo compliance applications? And
what is a purpose of the "MeeGo compliant application" concept?
Alexey Khoroshilov,
ISPRAS / Linux Foundation
_______________________________________________
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
