On 16/09/10 19:50, Tanu Kaskinen wrote:
If no external dependencies are allowed, the device vendor only has the
burden of providing the core api. Since every device provides this api,
every compliant app is guaranteed to be able to run on the device. If a
developer wants an application to run on all Meego devices, the
developer has only one task: get the app in enough repositories so that
they together cover every Meego device.
If external dependencies, let's say to compliant software in the
Surrounds repo, are allowed, then the device vendor must provide access
to the Surrounds repo. That is the additional burden.
Agreed. See my wording proposal to the spec:
Applications *MUST NOT* require (in RPM terminology) packages that are not
themselves compliant.
Applications that require (in RPM terminology) packages that cannot be provided
MUST NOT be installed.
Ta da... burden lifted. Surrounds friendly vendors (like Nokia) can still
support MeeGo compliant Extras that make use of Surrounds.
Nasty and mean vendors who don't want to risk killing all the people in their
car (ok, that makes them not-so-mean) don't provide access to Surrounds and must
not install Extras apps.
Now you probably
ask why it is mandatory to provide access to Surrounds. Because if it's
not mandatory, and a developer wants the application to run on all Meego
devices, then the developer has two tasks: get the app in enough
repositories so that they together cover every Meego device AND convince
the all device vendors to enable the Surrounds repo.
Not at all.
That risk is assumed by a developer who uses Surrounds.
http://wiki.meego.com/images/MeeGo-Compliance-Spec-1.0.80.8.pdf line 157
No right minded commercial vendor will do this; nor will any GPL vendor aiming
for mass market appeal.
The objective is *not* to get Surrounds into devices by the back door.... it is
to *not forbid* the eventual inclusion. Massive difference. Caveat Developer.
The difference between the two tasks is that getting an app in enough
repositories is not necessarily a technical problem, and hopefully
possible to solve in most cases, but getting all device vendors to
enable some external repo (e.g. Surrounds) is probably pretty
impossible.
It is pretty damned hard.
Is it easier if the spec says "Applications using the optional Surrounds repo
are compliant"
Now, if the spec says "Applications using the optional Surrounds repo are not
compliant"
Which one bodes well for the long term acceptance of Surrounds?
Maemo has shown it can be done. Nokia enable Maemo Community Extras *by default*
on their top-end device... the N900. And they promised (?) to do this in the
future... but only when you don't buy a subsidised carrier version.
Now... when vendors sell an unsubsidised version of a device they *could* follow
Nokias lead.... but they won't if it's against the spec.
Therefore, allowing external dependencies causes severe
fragmentation among "Meego Compliant" applications. There are probably
Meego compliant applications that have no chance to get accepted in all
repositories, which also causes fragmentation, but I guess people are
expecting that fragmentation to be small enough to be tolerable.
I was a bit disappointed when I realized this. This means that many
"Meego Compliant" applications will contain who knows how old and
insecure library versions bundled with the main app. The "Meego
Compliant" label won't have any value for me personally, I'll stick to
the properly packaged Extras...
Indeed... and if we slowly and gently make people aware of the benefits ... and
haven't pre-emptively branded 'Surrounds/Extras' as non-compliant... then we can
start to influence them.
David
--
"Don't worry, you'll be fine; I saw it work in a cartoon once..."
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
