On 17/09/10 17:58, Skarpness, Mark wrote:
On Sep 16, 2010, at 1:38 PM, David Greaves wrote:
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.
>
I'm not comfortable with this because it effectively creates two types of
compliant apps: those that rely only on the dependencies satisfied by a
compliant device and those that rely on external dependencies.
Yes, I see what you are concerned about. Lets look at this in more detail.
This reduces
the available market for a given app
Very true. I've already said that I'd expect Caveat Developer when it comes to
using Surrounds though. Here's why:
I think we accept that some MeeGo devices will be designed to be out of reach.
MeeGo IVI seems the most likely device class that simply will not run 'random'
use installed apps. (Correct me if this is wrong).
We've also noted that app stores will not be forced to carry all applications.
They will have a policy - be it QA oriented, legal or other.
Now, given that there is no promise that the available market for an application
is the entire set of devices, then the developer will make a series of choices
that may impact what fraction they can expect to target. The decision to use
Surrounds is one of those - and yes, initially I exepct it to be a huge
limitation in "the real world" ... but that will be OK for some developers.
and also has the potential to create end
user confusion (how do I know which type of compliant app my device will
run?).
What is the promise to the user here?
I think it is: "If you _install_ a compliant app then it will work?"
Or is there a promise and expectation that *any* compliant app a user can "get
hold off" will install and work? This sounds unlikely.
So a key question to aid understanding: how do you see a user getting into a
situation where they have a compliant app that uses Surrounds and yet don't have
access to Surrounds?
I suggest that any device that has gives the user the ability to go out onto the
internet and download a random rpm and install it will also allow the Surrounds
repo to be enabled. (The maemo .install file specifically supported this years ago)
An app store that allows apps that depend on Surrounds will also have Surrounds
enabled on the target devices.
When you think about it - there is a stunningly high probability that a normal
user will simply not see compliant apps that require dependencies that cannot be
met.
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.
>
I disagree here - if a vendor sees enough value in the content of Extras,
then they will include it. "MeeGo compliant" is not a statement of worth - I
expect we'll see many vendors doing vendor-specific apps to show off unique
features of their devices - and that's fine.
And that isn't what is being asked.
Of course vendors will allow their own apps into their own store.
However, do you think that it is more or less likely that a store will permit
apps labelled compliant?
Will users be more or less likely to want a compliant app?
I *want* to write MeeGo compliant apps... they *will* run on every compliant
device (provided the appropriate powers permit the installation). They *are*
compliant.
"MeeGo compliant" simply means
that this app is guaranteed to run on every compliant device.
In reality there are many caveats... the biggest relevant exception is:
"This app is guaranteed to run on every compliant device.... except where
prevented by policy".
Surrounds based compliant apps meet that criteria.
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
