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. This reduces the available market for a given app and also has the potential to create end user confusion (how do I know which type of compliant app my device will run?). > > 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. 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. "MeeGo compliant" simply means that this app is guaranteed to run on every compliant device. > >> 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
_______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
