dear all??
Hello, we are developers who devotes ourselves to Firefox OS , our
business has been investing plenty of employees to study the system, we are
optimistic about the future development of this system , recently, we has
learned that the prototype custom machine ZET V788D has been announced, would
you like to tell us how can we get this phone?
------------------ Original ------------------
From: "dev-b2g-request"<[email protected]>;
Date: Thu, Sep 27, 2012 09:44 AM
To: "dev-b2g"<[email protected]>;
Subject: dev-b2g Digest, Vol 14, Issue 46
Send dev-b2g mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.mozilla.org/listinfo/dev-b2g
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dev-b2g digest..."
Today's Topics:
1. Re: Push API Permission (Justin Lebar)
2. Re: Push API Permission (ANTONIO MANUEL AMAYA CALVO)
3. Problems on building Firefox OS on OS X 10.8
(Fauzan Alfi Agirachman)
4. Re: Now does B2G support optimus L5 phone? (bin guo)
----------------------------------------------------------------------
Message: 1
Date: Wed, 26 Sep 2012 19:46:48 -0400
From: Justin Lebar <[email protected]>
To: ANTONIO MANUEL AMAYA CALVO <[email protected]>
Cc: DANIEL JESUS COLOMA BAIGES <[email protected]>, CARMEN JIMENEZ
CABEZAS <[email protected]>, ptheriault <[email protected]>,
Lucas
Adamski <[email protected]>, "[email protected] list"
<[email protected]>
Subject: Re: [b2g] Push API Permission
Message-ID:
<cafwcpz7hlec2of5qkg+pvgon77n8ia_ogjrrsz5i_e6ctmh...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
> But I still think that's a client implementation decision, not something
> that's
> forced by the way the protocol works.
It's not a client implementation decision, sorry. It's baked into the
protocol, and the protocol as posted in the bug bakes this in so that
we have to wake up the application.
If you wanted to design something like Apple's notification service,
then messages sent by application servers would need to specify a
message type:
* "stick this in the notification bar"
* "update the 'badge' next to the app icon (e.g., update an unread
message count)"
* "wake up the app and let it handle the notification".
Without this distinction built in to the protocol, we're forced to
wake up the app on all notifications, because that's the most general
case.
The protocol spec attached to bug does not make this distinction.
I guess you answered my question as to how this design decision came
about. Thanks.
-Justin
On Wed, Sep 26, 2012 at 7:30 PM, ANTONIO MANUEL AMAYA CALVO <[email protected]> wrote:
> On 27/09/2012, at 00:59, "Justin Lebar" <[email protected]> wrote:
>
>>> Yeah, that was my understanding too, but then I was told that
>>> notifications actually launched the app if it wasn't running in the
>>> first place.
>>
>> I would be curious to learn when this switch was made. The protocol
>> implemented by Telefonica in the bug forces us to wake up the app on
>> every notification, but everyone I've spoken with has said that they
>> thought we were doing this differently. So I wonder at what point a
>> decision was made to switch, and why.
>
> Actually I've seen the protocol since it was in draft and I had still assumed
> that the way it would work would be as Paul said, and as iOS does: when a
> notification is received, if the app is running it goes to the app, and
> otherwise it goes on the notification panel until the user chooses to
> activate the app. The protocol is quite similar to iOS one... and if in iOS
> it doesn't force us to launch/wake up the app, I don't know why here it does.
>
> I'm fact it wasn't until I read your messages on the bug talking about the
> applications polling when I started thinking that something was amiss since
> on my view of the world :P applications couldn't poll since they probably
> wouldn't be running in the first place. Then I asked around and I was told
> that apps were going to be awoken on notification reception. But I still
> think that's a client implementation decision, not something that's forced by
> the way the protocol works.
>
>
>>
>> Personally, I don't think that waking up the app is so bad; it allows
>> us to make the API simpler in many respects. But that's a separate
>> question from wanting to know why we changed.
>
> Waking up the app on notification reception isn't a bad idea. Is an awful
> one, specially if the permission is implicit. Doing it so means that you've
> actually give up all control about what's running on your device. Any
> application could use the notification API and then the developer (and not
> you anymore) would choose when the app was going to run on your device.
>
> Even for "good" applications that wouldn't be cool. For malicious apps it's a
> heaven's gift: an attacker can choose when and how his code is going to run.
> Makes all the attacks that require a malicious app actually running on the
> deceive so much easier.
>
> To keep it this way (and again, I think this should be a separate issue from
> the ones that have risen on the patch review, since it isn't or should not be
> protocol related) the permission would have to be at least explicit for
> installed (and I would say even privileged). It would be even better if we
> could have two different permissions: one that lets the apps use an iOS like
> notification system (user must launch the app) and other, more restricted,
> that allows some apps to be launched remotely. I can't think on any use case
> for the second one to be honest, but I'm pretty sure that someone someplace
> will have a perfect use case for that.
>
> And yes, I know the date we're on ;).
>
> Un saludo,
>
> Antonio
>
>
>
>>
>> On Wed, Sep 26, 2012 at 6:08 PM, Antonio Manuel Amaya Calvo <[email protected]>
>> wrote:
>>> On 26/09/2012 23:09, ptheriault wrote:
>>>>
>>>> Antonio,
>>>>
>>>> I was surprised to see that too - my guess is that it was a guess from
>>>> long ago before push API was defined. On monday I created a version 1.0 of
>>>> the matrix with many updates and corrections (including this) and sent it
>>>> to
>>>> the b2g list. Below are links to the new matrix, and the change
>>>> log/question
>>>> list:
>>>>
>>>> Permissions Matrix 1.0:
>>>> https://docs.google.com/spreadsheet/ccc?key=0Akyz_Bqjgf5pdHNlbDBDUGMzUzJSdFYyNEZjcngtUWc
>>>> 1.0 version changes: https://etherpad.mozilla.org/permissionmatrixupdates
>>>
>>>
>>> Thanks for the new version, somehow I missed that update.
>>>
>>>
>>>>
>>>> (for reference, the change I made was to update permissions to match the
>>>> wiki. Also I wasnt sure if there is a Mgmt API which allows the system to
>>>> know what push notifications are registered?)
>>>>
>>>> Now to your concern about apps launching - is your fear that apps can keep
>>>> themselves running by sending push notifications?
>>>> My understanding of the way Push Notifications were handled was that there
>>>> was user interaction in the process - i.e. they show up in the
>>>> notifications
>>>> tray, and then, only after the user has tapped on the notification the app
>>>> is relaunched.
>>>
>>>
>>> Yeah, that was my understanding too, but then I was told that
>>> notifications actually launched the app if it wasn't running in the
>>> first place. Which if finally is what sees the light, makes it an
>>> explicit permission (at least) in my book :)
>>>
>>> Best regards,
>>>
>>> Antonio
>>>
>>>
>>>>
>>>> Regards,
>>>> Paul
>>>>
>>>>
>>>> On Sep 26, 2012, at 8:34 PM, Antonio Manuel Amaya Calvo wrote:
>>>>
>>>>> Hey Paul.
>>>>>
>>>>> I've seen that on the permission matrix at
>>>>>
>>>>> https://docs.google.com/spreadsheet/ccc?key=0Akyz_Bqjgf5pdENVekxYRjBTX0dCXzItMnRyUU1RQ0E&pli=1#gid=0
>>>>> the PushAPI is reserved to certified apps only, when it used to be a
>>>>> Public API (according to
>>>>> https://wiki.mozilla.org/WebAPI/Security/pushNotificationsAPI at least).
>>>>>
>>>>> Do you know why and when was that changed?
>>>>>
>>>>> I was in fact going to suggest either changing the way the system treats
>>>>> notification currently (from what I've been told, the system *launches*
>>>>> the app if it isn't running, which isn't good) or at least making it an
>>>>> explicit permission for anything less than privileged, but just removing
>>>>> the permission completely for anything less than certified seems a
>>>>> little bit extreme.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Antonio
>>>>>
>>>>>
>>>>> --
>>>>> Antonio Manuel Amaya Calvo_/ / _ /Security&Trust on N&S
>>>>> email: [email protected] / _ _/ ( / Telefonica I+D
>>>>> Tlf.: +34-91.312.98.95 _/ _/ \__/ D. Ram?n de la Cruz 82
>>>>> Fax : 28006 Madrid, SPAIN
>>>>>
>>>>> ________________________________
>>>>>
>>>>> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
>>>>> nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace
>>>>> situado m?s abajo.
>>>>> This message is intended exclusively for its addressee. We only send and
>>>>> receive email on the basis of the terms set out at:
>>>>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>>>>
>>>> testResults['bluetooth']
>>>>
>>>
>>> --
>>> Antonio Manuel Amaya Calvo_/ / _ /Security&Trust on N&S
>>> email: [email protected] / _ _/ ( / Telefonica I+D
>>> Tlf.: +34-91.312.98.95 _/ _/ \__/ D. Ram?n de la Cruz 82
>>> Fax : 28006 Madrid, SPAIN
>>>
>>> ________________________________
>>>
>>> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
>>> nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace
>>> situado m?s abajo.
>>> This message is intended exclusively for its addressee. We only send and
>>> receive email on the basis of the terms set out at:
>>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>>> _______________________________________________
>>> dev-b2g mailing list
>>> [email protected]
>>> https://lists.mozilla.org/listinfo/dev-b2g
>
> ________________________________
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
> nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace
> situado m?s abajo.
> This message is intended exclusively for its addressee. We only send and
> receive email on the basis of the terms set out at:
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
------------------------------
Message: 2
Date: Wed, 26 Sep 2012 23:59:17 +0000
From: ANTONIO MANUEL AMAYA CALVO <[email protected]>
To: Justin Lebar <[email protected]>
Cc: DANIEL JESUS COLOMA BAIGES <[email protected]>, CARMEN JIMENEZ
CABEZAS <[email protected]>, ptheriault <[email protected]>,
Lucas
Adamski <[email protected]>, "[email protected] list"
<[email protected]>
Subject: Re: [b2g] Push API Permission
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
On 27/09/2012, at 01:46, "Justin Lebar" <[email protected]> wrote:
>> But I still think that's a client implementation decision, not something
>> that's
>> forced by the way the protocol works.
>
> It's not a client implementation decision, sorry. It's baked into the
> protocol, and the protocol as posted in the bug bakes this in so that
> we have to wake up the application.
>
> If you wanted to design something like Apple's notification service,
> then messages sent by application servers would need to specify a
> message type:
>
> * "stick this in the notification bar"
> * "update the 'badge' next to the app icon (e.g., update an unread
> message count)"
> * "wake up the app and let it handle the notification".
>
> Without this distinction built in to the protocol, we're forced to
> wake up the app on all notifications, because that's the most general
> case.
>
> The protocol spec attached to bug does not make this distinction.
Nor should it. Unless we want to get creative with badges as some iOS apps do:
* Want a badge number? The system knows how many notifications have fetched for
an app and haven't been delivered. We got the badge number.
* Want to do whar to do with the notification? If the application is running,
pass the notification to the app. Otherwise, stick it on the notification bar.
No need to distinguish anything on the protocol per se although I agree that
the expected client behavior should be documented.
And once again we're arguing about the protocol, several months too late. We
disagree on that, we can leave that there until a decision is taken.
Anyway, I didn't start this as another argument about the protocol, we already
have the bug for that :P.
Whatever the reason was, it doesn't matter. Whatever the protocol finally is,
what are we going to do with notifications and how that affects the permissions
needed should be the argument here (even if it's just to take note of something
else that must be considered).
>
> I guess you answered my question as to how this design decision came
> about. Thanks.
Did I? You're welcome then I guess
Un saludo,
Antonio
>
> -Justin
>
> On Wed, Sep 26, 2012 at 7:30 PM, ANTONIO MANUEL AMAYA CALVO <[email protected]>
> wrote:
>> On 27/09/2012, at 00:59, "Justin Lebar" <[email protected]> wrote:
>>
>>>> Yeah, that was my understanding too, but then I was told that
>>>> notifications actually launched the app if it wasn't running in the
>>>> first place.
>>>
>>> I would be curious to learn when this switch was made. The protocol
>>> implemented by Telefonica in the bug forces us to wake up the app on
>>> every notification, but everyone I've spoken with has said that they
>>> thought we were doing this differently. So I wonder at what point a
>>> decision was made to switch, and why.
>>
>> Actually I've seen the protocol since it was in draft and I had still
>> assumed that the way it would work would be as Paul said, and as iOS does:
>> when a notification is received, if the app is running it goes to the app,
>> and otherwise it goes on the notification panel until the user chooses to
>> activate the app. The protocol is quite similar to iOS one... and if in iOS
>> it doesn't force us to launch/wake up the app, I don't know why here it does.
>>
>> I'm fact it wasn't until I read your messages on the bug talking about the
>> applications polling when I started thinking that something was amiss since
>> on my view of the world :P applications couldn't poll since they probably
>> wouldn't be running in the first place. Then I asked around and I was told
>> that apps were going to be awoken on notification reception. But I still
>> think that's a client implementation decision, not something that's forced
>> by the way the protocol works.
>>
>>
>>>
>>> Personally, I don't think that waking up the app is so bad; it allows
>>> us to make the API simpler in many respects. But that's a separate
>>> question from wanting to know why we changed.
>>
>> Waking up the app on notification reception isn't a bad idea. Is an awful
>> one, specially if the permission is implicit. Doing it so means that you've
>> actually give up all control about what's running on your device. Any
>> application could use the notification API and then the developer (and not
>> you anymore) would choose when the app was going to run on your device.
>>
>> Even for "good" applications that wouldn't be cool. For malicious apps it's
>> a heaven's gift: an attacker can choose when and how his code is going to
>> run. Makes all the attacks that require a malicious app actually running on
>> the deceive so much easier.
>>
>> To keep it this way (and again, I think this should be a separate issue from
>> the ones that have risen on the patch review, since it isn't or should not
>> be protocol related) the permission would have to be at least explicit for
>> installed (and I would say even privileged). It would be even better if we
>> could have two different permissions: one that lets the apps use an iOS like
>> notification system (user must launch the app) and other, more restricted,
>> that allows some apps to be launched remotely. I can't think on any use case
>> for the second one to be honest, but I'm pretty sure that someone someplace
>> will have a perfect use case for that.
>>
>> And yes, I know the date we're on ;).
>>
>> Un saludo,
>>
>> Antonio
>>
>>
>>
>>>
>>> On Wed, Sep 26, 2012 at 6:08 PM, Antonio Manuel Amaya Calvo <[email protected]>
>>> wrote:
>>>> On 26/09/2012 23:09, ptheriault wrote:
>>>>>
>>>>> Antonio,
>>>>>
>>>>> I was surprised to see that too - my guess is that it was a guess from
>>>>> long ago before push API was defined. On monday I created a version 1.0
>>>>> of
>>>>> the matrix with many updates and corrections (including this) and sent it
>>>>> to
>>>>> the b2g list. Below are links to the new matrix, and the change
>>>>> log/question
>>>>> list:
>>>>>
>>>>> Permissions Matrix 1.0:
>>>>> https://docs.google.com/spreadsheet/ccc?key=0Akyz_Bqjgf5pdHNlbDBDUGMzUzJSdFYyNEZjcngtUWc
>>>>> 1.0 version changes: https://etherpad.mozilla.org/permissionmatrixupdates
>>>>
>>>>
>>>> Thanks for the new version, somehow I missed that update.
>>>>
>>>>
>>>>>
>>>>> (for reference, the change I made was to update permissions to match the
>>>>> wiki. Also I wasnt sure if there is a Mgmt API which allows the system to
>>>>> know what push notifications are registered?)
>>>>>
>>>>> Now to your concern about apps launching - is your fear that apps can keep
>>>>> themselves running by sending push notifications?
>>>>> My understanding of the way Push Notifications were handled was that there
>>>>> was user interaction in the process - i.e. they show up in the
>>>>> notifications
>>>>> tray, and then, only after the user has tapped on the notification the app
>>>>> is relaunched.
>>>>
>>>>
>>>> Yeah, that was my understanding too, but then I was told that
>>>> notifications actually launched the app if it wasn't running in the
>>>> first place. Which if finally is what sees the light, makes it an
>>>> explicit permission (at least) in my book :)
>>>>
>>>> Best regards,
>>>>
>>>> Antonio
>>>>
>>>>
>>>>>
>>>>> Regards,
>>>>> Paul
>>>>>
>>>>>
>>>>> On Sep 26, 2012, at 8:34 PM, Antonio Manuel Amaya Calvo wrote:
>>>>>
>>>>>> Hey Paul.
>>>>>>
>>>>>> I've seen that on the permission matrix at
>>>>>>
>>>>>> https://docs.google.com/spreadsheet/ccc?key=0Akyz_Bqjgf5pdENVekxYRjBTX0dCXzItMnRyUU1RQ0E&pli=1#gid=0
>>>>>> the PushAPI is reserved to certified apps only, when it used to be a
>>>>>> Public API (according to
>>>>>> https://wiki.mozilla.org/WebAPI/Security/pushNotificationsAPI at least).
>>>>>>
>>>>>> Do you know why and when was that changed?
>>>>>>
>>>>>> I was in fact going to suggest either changing the way the system treats
>>>>>> notification currently (from what I've been told, the system *launches*
>>>>>> the app if it isn't running, which isn't good) or at least making it an
>>>>>> explicit permission for anything less than privileged, but just removing
>>>>>> the permission completely for anything less than certified seems a
>>>>>> little bit extreme.
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Antonio
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Antonio Manuel Amaya Calvo_/ / _ /Security&Trust on N&S
>>>>>> email: [email protected] / _ _/ ( / Telefonica I+D
>>>>>> Tlf.: +34-91.312.98.95 _/ _/ \__/ D. Ram?n de la Cruz 82
>>>>>> Fax : 28006 Madrid, SPAIN
>>>>>>
>>>>>> ________________________________
>>>>>>
>>>>>> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
>>>>>> nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace
>>>>>> situado m?s abajo.
>>>>>> This message is intended exclusively for its addressee. We only send and
>>>>>> receive email on the basis of the terms set out at:
>>>>>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>>>>>
>>>>> testResults['bluetooth']
>>>>>
>>>>
>>>> --
>>>> Antonio Manuel Amaya Calvo_/ / _ /Security&Trust on N&S
>>>> email: [email protected] / _ _/ ( / Telefonica I+D
>>>> Tlf.: +34-91.312.98.95 _/ _/ \__/ D. Ram?n de la Cruz 82
>>>> Fax : 28006 Madrid, SPAIN
>>>>
>>>> ________________________________
>>>>
>>>> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
>>>> nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace
>>>> situado m?s abajo.
>>>> This message is intended exclusively for its addressee. We only send and
>>>> receive email on the basis of the terms set out at:
>>>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>>>> _______________________________________________
>>>> dev-b2g mailing list
>>>> [email protected]
>>>> https://lists.mozilla.org/listinfo/dev-b2g
>>
>> ________________________________
>>
>> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
>> nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace
>> situado m?s abajo.
>> This message is intended exclusively for its addressee. We only send and
>> receive email on the basis of the terms set out at:
>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace
situado m?s abajo.
This message is intended exclusively for its addressee. We only send and
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
------------------------------
Message: 3
Date: Thu, 27 Sep 2012 08:21:23 +0700
From: Fauzan Alfi Agirachman <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [b2g] Problems on building Firefox OS on OS X 10.8
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hello everyone,
I want to give a short demo of Firefox OS this Friday but until now the B2G
nightly build that I built on OS X is not working. It only gives me
lockscreen[1], homescreen without any app icon [2] + with broken notification
center. [3]
I'm only following the instruction on https://wiki.mozilla.org/Gaia/Hacking. I
also attach all relevant screenshot.
Do you have any solution for this problem?
Regards,
Fauzan Alfi
Mozilla Representative, Indonesia
https://reps.mozilla.org/u/fauzanalfi/
[1] http://d.pr/i/Rusf
[2] http://d.pr/i/Kulw
[3] http://d.pr/i/MKNT
------------------------------
Message: 4
Date: Wed, 26 Sep 2012 18:44:06 -0700 (PDT)
From: bin guo <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [b2g] Now does B2G support optimus L5 phone?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, September 26, 2012 3:59:44 PM UTC+8, bin guo wrote:
> Hello,
>
> As title. I ran "./config.sh optimus-l5", "./build.sh", and got this error:
>
>
>
> /usr/bin/perl
> /home/rubin/Desktop/Dev/gecko/local/B2G/gecko/toolkit/mozapps/installer/xptlink.pl
> -s ../../dist -d ../../dist/xpt -f ../../dist/b2g//components -v -x
> "/home/rubin/Desktop/Dev/gecko/local/B2G/objdir-gecko/_virtualenv/bin/python
> /home/rubin/Desktop/Dev/gecko/local/B2G/objdir-gecko/dist/sdk/bin/xpt.py link"
>
> Error: destination directory "../../dist/xpt" is not a directory or is not
> writeable.
>
> See
> '/home/rubin/Desktop/Dev/gecko/local/B2G/gecko/toolkit/mozapps/installer/xptlink.pl
> --help' for more information.
>
> Exiting...
>
> make[4]: *** [stage-package] Error 2
>
> make[4]: Leaving directory
> `/home/rubin/Desktop/Dev/gecko/local/B2G/objdir-gecko/b2g/installer'
>
> make[3]: *** [make-package] Error 2
>
> make[3]: Leaving directory
> `/home/rubin/Desktop/Dev/gecko/local/B2G/objdir-gecko/b2g/installer'
>
> make[2]: *** [default] Error 2
>
> make[2]: Leaving directory
> `/home/rubin/Desktop/Dev/gecko/local/B2G/objdir-gecko/b2g/installer'
>
> make[1]: *** [package] Error 2
>
> make[1]: Leaving directory
> `/home/rubin/Desktop/Dev/gecko/local/B2G/objdir-gecko'
>
> make: *** [out/target/product/m4/obj/DATA/gecko_intermediates/gecko] Error 2
>
>
>
> BR,
>
> rubin
So, nobody know it...
------------------------------
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
End of dev-b2g Digest, Vol 14, Issue 46
***************************************
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
