On Tue, Sep 21, 2010 at 10:33:19AM +0300, Marius Vollmer wrote:
> However, the stores are also contstrained by what the devices are able
> to do.
Absolutely, a working solution needs the cooperation of all parts
(device, app, store).
> Right now, for example, packages for the N900 in the Ovi Stor
ext Lucas Maneos writes:
> On that I can only agree with Marius: This burden
> should be placed on the store.
However, the stores are also contstrained by what the devices are able
to do.
Right now, for example, packages for the N900 in the Ovi Store can not
have dependencies to packages in Mae
On Mon, Sep 20, 2010 at 11:37 PM, Nathan Anderson
mailto:nat...@andersonsplace.net>> wrote:
> > Here are some Real world numbers using real applications; pulled from
> Maemo
> > Repositories
> > ICU 4.2> 8 Megs
> > cLucene is> 3 Meg (Depends on ICU)
> > Sword> 2 Megs. (Depends on cLucene)
> > W
On Mon, Sep 20, 2010 at 05:52:35AM +0200, quim@nokia.com wrote:
> "Simply put, we want to make it possible for an application developer to
> write a MeeGo compliant application once and run it on any MeeGo compliant
> device."
> http://wiki.meego.com/Quality/Compliance
As others have pointe
Riku,
> Here are some Real world numbers using real applications; pulled from
Maemo
> Repositories
> ICU 4.2> 8 Megs
> cLucene is> 3 Meg (Depends on ICU)
> Sword> 2 Megs. (Depends on cLucene)
> WebKit> 3 Megs. (Depends on ICU 4.2)
> Lets say I just put TWO bible apps (Both use Sword) on the
On Sun, Sep 19, 2010 at 3:30 PM, Skarpness, Mark
wrote:
>
> As I said earlier in the thread - compliance isn't a statement of worth - it
>simply
> means that the app follows the rules of compliance so that it will run on any
> compliant device.
I think there is a big disconnect here... I think
On 09/20/10 13:21, Riku Voipio wrote:
> When we look at the usual case, for most libraries, embedding the to
> the applications is not going to be a problem. There is probably
> only going to be 1-3 users of that library anyways. For the few widely
> used libraries, we can have them in MeeGo core.
On Monday 20 September 2010 00:46:32 Skarpness, Mark wrote:
> On Sep 19, 2010, at 4:23 PM, Graham Cobb wrote:
> > Take the "compliant" word off the table, reduce the heat in this thread,
> > and let marketing do their job of brand creation, don't try to guess what
> > they will decide.
>
> Of cours
Em Segunda-feira 20 Setembro 2010, às 11:21:44, Riku Voipio escreveu:
> When we look at the usual case, for most libraries, embedding the to the
> applications is not going to be a problem. There is probably
> only going to be 1-3 users of that library anyways. For the few widely
> used libraries
On Mon, Sep 20, 2010 at 10:21, Riku Voipio wrote:
>
> Another thing people here seem to ignore: For developers *not* coming from
> linux distribution/packaging background, importing a shared library to their
> application project is infinitely simpler task than packaging the same
> library (correc
On 09/18/2010 02:43 AM, ext Nathan Anderson wrote:
I've watched this thread with interest the last week or so. Time to chip
in. :D
Here are some Real world numbers using real applications; pulled from Maemo
Repositories
ICU 4.2> 8 Megs
cLucene is> 3 Meg (Depends on ICU)
Sword> 2 Megs. (D
ext Anas Nashif writes:
> Packages having the same name and residing in different repos should not be a
> problem, since the package manager can deal with same package name from two
> different vendors.
Excellent! I was hoping that rpm/zypper/packagekit might have this
feature. Really nice.
__
On Mon, Sep 20, 2010 at 6:52 AM, wrote:
> > Why do we go back a few steps and figure out what goals we want to
> > achieve with this and then we can find the best way to go about it.
>
> "Simply put, we want to make it possible for an application developer to
> write a MeeGo compliant applicatio
"ext Skarpness, Mark" writes:
> On Sep 16, 2010, at 12:10 AM, Marius Vollmer wrote:
>
>> What about _internal_ dependencies? Should we allow applications to
>> have dependencies to other packages in the same store?
>
> From a compliance point of view, the application needs to be
> self-contained
"ext Skarpness, Mark" writes:
>> So which of the previous arguments against Surrounds are still valid?
>
> The burden placed on the device vendor to ensure that all possible
> external dependencies are available to every device.
This burden should be placed on the store.
The devices only carry
Ryan Abel wrote:
> Why do we go back a few steps and figure out what goals we want to
> achieve with this and then we can find the best way to go about it.
"Simply put, we want to make it possible for an application developer to write
a MeeGo compliant application once and run it on any MeeGo co
On Sep 19, 2010, at 4:23 PM, Graham Cobb wrote:
> On Sunday 19 September 2010 23:30:18 Skarpness, Mark wrote:
>> I want to make the marketing team job really simple - market "MeeGo
>> Compliant Applications"
>
> Sorry, my day job is marketing. We don't let engineers choose names! And
> for
>
On Sep 19, 2010, at 3:50 PM, Bernd Stramm wrote:
> On Sun, 19 Sep 2010 15:30:18 -0700
> "Skarpness, Mark" wrote:
>
>
>> That misses the point of compliance - the simple marketing concept is
>> "MeeGo compliant apps run on all MeeGo compliant devices". There's
>> nothing bad about apps that do
On Monday 20 September 2010 01:30:18 you wrote:
> Again we are basically back to two types of "compliant" apps. I strongly
> believe that is a mistake we cannot afford to make - we need to avoid
> fragmenting our application ecosystem.
We know we want to have bundled commercial apps targeting sto
On Sunday 19 September 2010 23:30:18 Skarpness, Mark wrote:
> I want to make the marketing team job really simple - market "MeeGo
> Compliant Applications"
Sorry, my day job is marketing. We don't let engineers choose names! And for
good reasons!!
I have no idea what brand MeeGo marketing will
On Sep 19, 2010, at 6:30 PM, Skarpness, Mark wrote:
> Yes, there is something non-compliant about componentised apps - they're
> non-compliant :-)
Why do we go back a few steps and figure out what goals we want to achieve with
this and then we can find the best way to go about it. Right now it
On Sun, 19 Sep 2010 15:30:18 -0700
"Skarpness, Mark" wrote:
> That misses the point of compliance - the simple marketing concept is
> "MeeGo compliant apps run on all MeeGo compliant devices". There's
> nothing bad about apps that don't meet the criteria - they just don't
> come with that promi
On Sep 19, 2010, at 3:12 AM, Graham Cobb wrote:
> On Saturday 18 September 2010 19:48:04 Skarpness, Mark wrote:
>> I don't agree that having MeeGo compliance support componentised
>> applications is an objective we should take for the near term. I would
>> rather us focus on solving the core pro
On Sep 19, 2010, at 6:48 AM, Bernd Stramm wrote:
> On Sun, 19 Sep 2010 11:12:50 +0100
> Graham Cobb wrote:
>
>> On Saturday 18 September 2010 19:48:04 Skarpness, Mark wrote:
>>> ...
>>> We can add this to a
>>> future version of compliance if everyone says "wow, that's great -
>>> I really want
On Sun, 19 Sep 2010 11:12:50 +0100
Graham Cobb wrote:
> On Saturday 18 September 2010 19:48:04 Skarpness, Mark wrote:
>>...
>> We can add this to a
> > future version of compliance if everyone says "wow, that's great -
> > I really want this on my next device"
IThis works against the very reaso
On Saturday 18 September 2010 19:48:04 Skarpness, Mark wrote:
> I don't agree that having MeeGo compliance support componentised
> applications is an objective we should take for the near term. I would
> rather us focus on solving the core problem (self-contained compliant app
> runs on any compli
On Saturday 18 September 2010 21:48:04 you wrote:
> Before we require compliant devices to support apps with external
> dependencies, I think we need to demonstrate that the value of that
> justifies the cost and complexity. For example - show what can be done
> with MeeGo Extras following this mo
On Sep 18, 2010, at 4:28 AM, David Greaves wrote:
> Allow me to invert this email and suggest some prioritisation.
>
> On 18/09/10 01:09, Skarpness, Mark wrote:
>
>> What we have been discussing on this thread is the guidelines themselves...
>
> Good point ... and I have made one of the very f
On Sep 18, 2010, at 9:05 AM, Gabriel Beddingfield wrote:
>>> Instead, why not leave "MeeGo Compliant Apps" alone and carve room in the
>>> spec for "MeeGo Extras." Either allow only one "Extras" repos. Or PREFIX
>>
>> Saying 'oh, not being compliant is not a big deal, look, we have thousands o
On Saturday 18 September 2010 19:05:52 you wrote:
> >> Instead, why not leave "MeeGo Compliant Apps" alone and carve room in
> >> the spec for "MeeGo Extras." Either allow only one "Extras" repos. Or
> >> PREFIX
> >
> > Saying 'oh, not being compliant is not a big deal, look, we have
> > thousan
>> Instead, why not leave "MeeGo Compliant Apps" alone and carve room in the
>> spec for "MeeGo Extras." Either allow only one "Extras" repos. Or PREFIX
>
> Saying 'oh, not being compliant is not a big deal, look, we have thousands of
> non-compliant apps that are safe and run just fine !' sounds
On Saturday 18 September 2010 15:48:07 you wrote:
> First, this is a NO-OP. It basically says "applications must depend on a
> package set that ultimately is only depending on MeeGo." Of course!
> Otherwise it won't run.
No. Compliancy is more than just fulfilling dependencies, that's whole poin
On Saturday 18 September 2010 15:48:07 you wrote:
> > process through negotiation:
> >"this app needs X=,Y,Z"... "OK, can meet"..."here's the app"
>
> But app Q=,T,F
>
> But app T installs a file /usr/share/icons/kewl.png
> And app Y also installs a file /usr/share/icons/kewl.png
>
> Since T
On 18/09/10 13:48, Gabriel M. Beddingfield wrote:
Let's *NOT* try to make repsoitory-driven app sets "MeeGo Compliant."
Is this a proposal? Technical or policy?
An assumption?
As I said ... my objective is to permit (not mandate) MeeGo compliance for
applications developed using the open-sourc
On Saturday, September 18, 2010 06:28:42 am David Greaves wrote:
> My compliance wording proposal is:
>
> Applications *MUST NOT* require (in RPM terminology) packages that are not
> themselves compliant.
>
> Applications that require (in RPM terminology) packages that cannot be
> provided
> M
Allow me to invert this email and suggest some prioritisation.
On 18/09/10 01:09, Skarpness, Mark wrote:
> What we have been discussing on this thread is the guidelines themselves...
Good point ... and I have made one of the very few concrete proposals for
wording in this thread ... and AFAICS
On Friday 17 September 2010 20:29:06 you wrote:
> On the other hand, what are the deep issues underneath this long
> discussion? Let me try:
>
> - The belief that the MeeGo official AOPI is not enough to satisfy
> developers. If this is true then it's a problem in itself and needs to
> be fixed by
On Sep 17, 2010, at 4:43 PM, Will Marone wrote:
> On 9/17/2010 12:02 PM, Quim Gil wrote:
>> On Thu, 2010-09-16 at 12:13 +0200, ext Jeremiah Foster wrote:
>>
>>> Forcing Extras out of compliance means you are disenfranchising your
>>> community.
>>
>> No. Hosting any kind of free software apps a
On 9/17/2010 12:02 PM, Quim Gil wrote:
On Thu, 2010-09-16 at 12:13 +0200, ext Jeremiah Foster wrote:
Forcing Extras out of compliance means you are disenfranchising your
community.
No. Hosting any kind of free software apps and libraries regardless of
their official/unofficial , compliant/non
I've watched this thread with interest the last week or so. Time to chip
in. :D
>>- The belief that there will be a significant amount of apps using other
>>APIs / toolkits. Which ones, though? PySide? KDE libs? Hildon? This
>>discussion would be better grounded if sustained by real maintainer
On Thu, 2010-09-16 at 12:13 +0200, ext Jeremiah Foster wrote:
> Forcing Extras out of compliance means you are disenfranchising your
> community.
No. Hosting any kind of free software apps and libraries regardless of
their official/unofficial , compliant/non-compliant and unstable/stable
status m
On Fri, 2010-09-17 at 08:58 +0200, Kellomaki Pertti (Nokia-MS/Tampere)
wrote:
> This may be completely left field, but from the discussion so far it
> seems that it could in fact be a lot easier to bless repositories (or
> sets therof) as MeeGo compliant, rather than single packages.
Actually
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 a
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 Wed, Sep 15, 2010 at 11:55:17AM +0200, Dave Neary wrote:
> That should be, "In theory, allowing dependencies will reduce the
> average space used when installing 100 apps, but it does not give a
> decent way to evaluate the maximum space needed for 100 apps".
IMHO this is a "how long is a piece
On 2010-09-17, at 2:49 PM, Nicolas Dufresne wrote:
> Le vendredi 17 septembre 2010 à 14:29 +0100, Anas Nashif a écrit :
>> Packages having the same name and residing in different repos should not be
>> a problem, since the package manager can deal with same package name from
>> two different ve
Le vendredi 17 septembre 2010 à 14:29 +0100, Anas Nashif a écrit :
> Packages having the same name and residing in different repos should
> not be a problem, since the package manager can deal with same package
> name from two different vendors.
This answer might be outside the subject scope, but
Le vendredi 17 septembre 2010 à 14:29 +0100, Anas Nashif a écrit :
> Packages having the same name and residing in different repos should
> not be a problem, since the package manager can deal with same package
> name from two different vendors.
This answer might be outside the subject scope, but
On 2010-09-16, at 10:40 PM, Nicolas Dufresne wrote:
> Le jeudi 16 septembre 2010 à 20:49 +0100, Andrew Flegg a écrit :
>>
>> Is there some technical or theoretical reason that *couldn't* work?
> Actually users will have problems when two repositories start providing same
> package (name clash o
On Fri, Sep 17, 2010 at 12:40 AM, Nicolas Dufresne <
nicolas.dufre...@collabora.co.uk> wrote:
> Actually users will have problems when two repositories start providing
> same package (name clash or file clash) and user problems result in customer
> support fees.
>
>
The name clash is actually tal
As it appears there is clearly no any kind of agreement on what to do
with repositories and dependencies, perhaps it would be best to drop
the requirement from the spec and revisit it later?
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meeg
On 09/13/2010 11:53 PM, Quim Gil wrote:
On 09/13/2010 12:04 PM, ext Alexey Khoroshilov wrote:
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
This may be completely left field, but from the discussion so far it
seems that it could in fact be a lot easier to bless repositories (or
sets therof) as MeeGo compliant, rather than single packages.
--
Pertti
___
MeeGo-dev mailing list
MeeGo-dev@mee
On Fri, Sep 17, 2010 at 12:23 AM, Tim Teulings wrote:
>
> So bobapp's web page and package description would say:
> * This is the wonderful bobapp. It is Meego compliant for Device Zupp and
> Device Wusch but not for Device ExtraLess.
>
> Is this the kind of complicance statement that e.g. market
On Friday 17 September 2010 00:44:43 you wrote:
> this is where you get in trouble if vendor Z ships libbar but in a
> different configuration/version for some widgety nifty thing that they
> do... ... and that version/configuration is not ABI compatible.
...which is not that much of an issue, bec
On Thursday 16 September 2010 22:44:43 Arjan van de Ven wrote:
> this is where you get in trouble if vendor Z ships libbar but in a
> different configuration/version for some widgety nifty thing that they
> do... ... and that version/configuration is not ABI compatible.
So, instead, you propose th
On 16/09/10 23:13, Arjan van de Ven wrote:
On 9/16/2010 3:05 PM, David Greaves wrot
That is indeed why I said Nokia, not Vodafone.
Vodafone probably won't allow Surrounds/Extras (initially) - but at
the idea is that at least they won't be able to say "you're not
compliant".
Nokia, as you know,
On 9/16/2010 3:05 PM, David Greaves wrot
That is indeed why I said Nokia, not Vodafone.
Vodafone probably won't allow Surrounds/Extras (initially) - but at
the idea is that at least they won't be able to say "you're not
compliant".
Nokia, as you know, ships the N900 with Extras enabled out
(high latency due to draft email hiding behind open windows)
On 16/09/10 15:03, Arjan van de Ven wrote:
On 9/16/2010 4:06 AM, David Greaves wrote:
On 16/09/10 11:26, Arjan van de Ven wrote:
But to be honest, I somewhat doubt that hardware vendors or the
operators will think more than a few sec
On 9/16/2010 1:45 PM, Andrew Flegg wrote:
On Thu, Sep 16, 2010 at 21:04, Skarpness, Mark wrote:
On Sep 16, 2010, at 12:49 PM, Andrew Flegg wrote:
Make compliance of a package dependent on the ability of the
repository to guarantee that all its dependencies can be met.
For Extras/Surrounds th
Le jeudi 16 septembre 2010 à 20:49 +0100, Andrew Flegg a écrit :
>
> Is there some technical or theoretical reason that *couldn't* work?
Actually users will have problems when two repositories start providing
same package (name clash or file clash) and user problems result in
customer support fe
On Thu, Sep 16, 2010 at 22:23, Tim Teulings wrote:
>
> This however means that there can be no central instance to decide if an
> application is compliant or not just based on the application package and
> its contents and thus an applications compliance is in relation to the
> platform it is runn
Hello!
Imagine that Nokia ship Extras and Ovi enabled in all their devices.
bobapp is in Ovi, and can be in MeeGo Compliant as only Nokia devices
can have Ovi and all Nokia devices have Extras available and enabled
to provide their dependencies.
However, if the bobapp developer uploaded the pac
Hello!
It seems that in your mind, each vendor will provide their own app
store,
it will be the very common case where the vendor will decide which of
the various app stores he will use.
appstores are 'the thing' nowadays, and Nokia and Intel each have their
own already I wouldn't be surp
On Thu, 2010-09-16 at 20:42 +0100, Andrew Flegg wrote:
> On Thu, Sep 16, 2010 at 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 guaran
On Thu, Sep 16, 2010 at 4:42 PM, Warren Baird
wrote:
>
> Earlier in the thread there was discussion around 2 levels of
> compliance - a 'strict' compliance that requires inclusion of all
> dependencies, and a more relaxed compliance that allows dependencies
> on an 'Extras' style repository...
Ju
On Thu, Sep 16, 2010 at 21:04, Skarpness, Mark wrote:
> On Sep 16, 2010, at 12:49 PM, Andrew Flegg wrote:
>
>> Make compliance of a package dependent on the ability of the
>> repository to guarantee that all its dependencies can be met.
>> For Extras/Surrounds that'd be itself and the Core.
>
> Yo
On Thu, Sep 16, 2010 at 2:44 PM, David Greaves wrote:
>
> I think we need to achieve 2 things:
> * permit the open-source development model to work for compliant
> applications
> * define the spec in a way to minimise the imposed burden on vendors
>
Thanks for trying to pull things back to the ba
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
actually, please ignore this email... I stand by it but I think maybe it is more
argumentative than constructive ... I was trying to get at the goals/objectives
but it's not well phrased.sorry if I offended.
The next one focuses on Mark's issues and has more concrete proposals.
David
On 1
On 16/09/10 21:00, Skarpness, Mark wrote:
On Sep 16, 2010, at 12:37 PM, Andrew Flegg wrote:
On Thu, Sep 16, 2010 at 19:09, Skarpness, Mark
wrote:
On Sep 16, 2010, at 10:42 AM, David Greaves wrote:
If I make a package that is api-compliant and self-contained and put it
in Extras then that can
On Thu, Sep 16, 2010 at 21:00, Skarpness, Mark wrote:
> On Sep 16, 2010, at 12:37 PM, Andrew Flegg wrote:
>
>>
>> Is that viable? A package can be Compliant if it's alongside its
>> dependencies (or if the installation of its dependencies, which must
>> be Compliant as well). Take the package *out
On 16/09/10 20:06, Arjan van de Ven wrote:
On 9/16/2010 11:44 AM, David Greaves wrote:
On 16/09/10 19:09, Skarpness, Mark wrote:
If the 2nd differs because it "depends" on the first one then what
additional burden exists?
As we have discussed repeatedly - the burden that a device must
provide
On Sep 16, 2010, at 12:49 PM, Andrew Flegg wrote:
> On Thu, Sep 16, 2010 at 20:45, Arjan van de Ven wrote:
>>
>> realistically, we can't even mandate the core meego.com repo.
>> Many of these vendors will run their own whole repo set
>
> Indeed. So mandate none. Make compliance of a packag
On Sep 16, 2010, at 12:37 PM, Andrew Flegg wrote:
> On Thu, Sep 16, 2010 at 19:09, Skarpness, Mark
> wrote:
>> On Sep 16, 2010, at 10:42 AM, David Greaves wrote:
>>>
>>> If I make a package that is api-compliant and self-contained and put it in
>>> Extras then that can be labelled compliant. B
On Thu, Sep 16, 2010 at 20:45, Arjan van de Ven wrote:
>
> realistically, we can't even mandate the core meego.com repo.
> Many of these vendors will run their own whole repo set
Indeed. So mandate none. Make compliance of a package dependent on the
ability of the repository to guarantee that
On 9/16/2010 12:42 PM, Andrew Flegg wrote:
On Thu, Sep 16, 2010Agreed.
Mandating Surrounds would be a burden. What about, then, as a
compromise going back to one of the earlier suggestions and saying
that each repo containing MeeGo Compliant packages can depend on a
well-defined set of other
On Thu, Sep 16, 2010 at 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 a
On Thu, Sep 16, 2010 at 19:09, Skarpness, Mark wrote:
> On Sep 16, 2010, at 10:42 AM, David Greaves wrote:
>>
>> If I make a package that is api-compliant and self-contained and put it in
>> Extras then that can be labelled compliant. By your definition it offers no
>> burden.
>>
>> If I install
On 9/16/2010 11:44 AM, David Greaves wrote:
On 16/09/10 19:09, Skarpness, Mark wrote:
If the 2nd differs because it "depends" on the first one then what
additional burden exists?
As we have discussed repeatedly - the burden that a device must
provide a way
to install the second app (or depend
Hello,
I was originally against Mark's ideas, but I think I finally got his
point. I'll try my best at explaining the argument as clearly as
possible.
On Thu, 2010-09-16 at 18:42 +0100, David Greaves wrote:
> On 16/09/10 17:24, Skarpness, Mark wrote:
> >
> > On Sep 16, 2010, at 4:36 AM, David Gre
On 16/09/10 19:09, Skarpness, Mark wrote:
If the 2nd differs because it "depends" on the first one then what
additional burden exists?
As we have discussed repeatedly - the burden that a device must provide a way
to install the second app (or dependency).
Can we agree our goals?
I think we ne
On Sep 16, 2010, at 10:42 AM, David Greaves wrote:
> On 16/09/10 17:24, Skarpness, Mark wrote:
>>
>> On Sep 16, 2010, at 4:36 AM, David Greaves wrote:
>>> So... a vendor has the freedom to forbid certain MeeGo compliant apps on
>>> their device/store?
>> Yes
>
> Good.
>
>>> If MeeGo then permi
On 16/09/10 17:24, Skarpness, Mark wrote:
On Sep 16, 2010, at 4:36 AM, David Greaves wrote:
So... a vendor has the freedom to forbid certain MeeGo compliant apps on
their device/store?
Yes
Good.
If MeeGo then permits Surrounds-dependent apps to be labelled "Compliant"
then there is no addi
On Sep 16, 2010, at 10:07 AM, Nicolas Dufresne wrote:
> Le jeudi 16 septembre 2010 à 19:47 +0300, Attila Csipa a écrit :
>> Does that mean that devices can 'lose' compliancy over time
> I think this should be solved with versionning. So program X can be shipped
> as being compliant to spec 1.0 a
On Sep 16, 2010, at 9:47 AM, Attila Csipa wrote:
On Thu, Sep 16, 2010 at 7:24 PM, Skarpness, Mark
mailto:mark.skarpn...@intel.com>> wrote:
> If MeeGo then permits Surrounds-dependent apps to be labelled "Compliant" then
> there is no addidional burden placed on a vendor since they can simply ref
Le jeudi 16 septembre 2010 à 19:47 +0300, Attila Csipa a écrit :
> Does that mean that devices can 'lose' compliancy over time
I think this should be solved with versionning. So program X can be
shipped as being compliant to spec 1.0 and lower. This indeed assumes
every major increments of the sp
On Sep 16, 2010, at 1:36 AM,
mailto:kate.alh...@nokia.com>>
mailto:kate.alh...@nokia.com>> wrote:
On Sep 16, 2010, at 1:02 AM, ext Skarpness, Mark wrote:
On Sep 15, 2010, at 1:16 PM, Graham Cobb wrote:
On Wednesday 15 September 2010 17:13:43 Skarpness, Mark wrote:
But that would mean that a
On Thu, Sep 16, 2010 at 7:24 PM, Skarpness, Mark
wrote:
> > If MeeGo then permits Surrounds-dependent apps to be labelled "Compliant"
> then
> > there is no addidional burden placed on a vendor since they can simply
> refuse to
> > allow them on their device/store?
> No - that is a different probl
On Sep 16, 2010, at 12:10 AM, Marius Vollmer wrote:
> "ext Skarpness, Mark" writes:
>
>> But my point was really that this decision does matter and does have
>> an impact - if we allow applications to have external dependencies
>> then someone has to pay to host them in a commercially scalable
On Sep 15, 2010, at 11:39 PM, Alexey Khoroshilov wrote:
> On 09/15/2010 08:13 PM, Skarpness, Mark wrote:
>> Hi Dave,
>> On Sep 15, 2010, at 1:51 AM, Dave Neary wrote:
>>> I can get that a commercial application developer wants to be able to
>>> build a package which will install on any MeeGo devi
On Sep 16, 2010, at 4:36 AM, David Greaves wrote:
> On 15/09/10 23:59, Skarpness, Mark wrote:
>> I view it the other way around: what requirements is compliance placing on
>> the device manufacturer and are those reasonable and supportable.
>>
>> Setting the details of how compliant apps are pa
On Thursday 16 September 2010 17:28:19 you wrote:
> > *IF THEY WOULD* and you downloaded a MeeGo compliant app that used a
> > Surrounds library would it work?
>
> So in case of a road death, who is liable for this Surrounds library
> exactly?
In case of a road death, who is liable for the MeeGo
- Original message -
> On 9/16/2010 4:06 AM, David Greaves wrote:
> > On 16/09/10 11:26, Arjan van de Ven wrote:
> > > But to be honest, I somewhat doubt that hardware vendors or the
> > > operators will think more than a few seconds and just not enable it,
> > > even if they were to ta
On 16/09/10 15:28, Anas Nashif wrote:
On 2010-09-16, at 12:20 PM, David Greaves wrote:
On 16/09/10 11:52, Counihan, Tom wrote:
The IVI vertical reflects the above, OEMs will most likely always lock down,
primarily driven from safety concerns - litigation and publicity concerns
over the potent
On Thu, 16 Sep 2010 15:28:19 +0100
Anas Nashif wrote:
>
> On 2010-09-16, at 12:20 PM, David Greaves wrote:
>
> > On 16/09/10 11:52, Counihan, Tom wrote:
> >>> [mailto:meego-dev-boun...@meego.com] On Behalf Of Arjan van de
> >>> Ven Sent: 16 I think that in practice, phones will be locked down
>
On 2010-09-16, at 12:20 PM, David Greaves wrote:
> On 16/09/10 11:52, Counihan, Tom wrote:
>>> [mailto:meego-dev-boun...@meego.com] On Behalf Of Arjan van de Ven Sent: 16
>>> I think that in practice, phones will be locked down and the content you
>>> can get on it controlled by the operator and/
On Thu, Sep 16, 2010 at 15:03, Arjan van de Ven wrote:
> On 9/16/2010 4:06 AM, David Greaves wrote:
>>
>> But forward looking and experienced companies like Nokia can enable
>> Surrounds and permit associated apps as they have done with Extras on the
>> N900.
>
> if you really think that Nokia wi
On 9/16/2010 4:06 AM, David Greaves wrote:
On 16/09/10 11:26, Arjan van de Ven wrote:
But to be honest, I somewhat doubt that hardware vendors or the
operators will think more than a few seconds and just not enable it,
even if they were to take the OS nearly directly from meego.com
Precisely.
>-Original Message-
>From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On
>Behalf Of David Greaves
>Sent: 16 September 2010 12:20
>To: meego-dev@meego.com
>Subject: Re: [MeeGo-dev] Meego spec - for comment
>
>On 16/09/10 11:52, Counihan, Tom
1 - 100 of 281 matches
Mail list logo
