Re: [RFC] doc: Add support for CMAS/EU-Alert

2011-02-22 Thread Denis Kenzior
Hi Jeeva,

On 02/21/2011 11:36 PM, jeevaka.badrap...@elektrobit.com wrote:
 Hi Rajesh,
 
 ofono-boun...@ofono.org wrote:
 Hi Jeeva,

 Is this WarningType really required on the App side ?
 Irrespective of the warning type, the emergency broadcast
 message handling won't change on the apps side (i.e, its
 going to be displayed immediately to the user). This can be
 achieved by the old boolean variable EmergencyAlert only ?

 
 Its Popup property which is used for displaying the
 messages immediately to the user. EmergencyAlert Property
 is used to hint whether an emergency indicator(Vibration, emergency
 tone)
 should be activated.
 
 Yes, agree that the WarningType is not really required. 
 May be it was there for some reason. This RFC patch just extends
 the existing EmergencyType property.

Lets just get rid of it then and keep the name EmergencyAlert.  Do we
want to re-model this using an Agent style API by any chance?

Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono


RE: [RFC] doc: Add support for CMAS/EU-Alert

2011-02-21 Thread Rajesh.Nagaiah
Hi Jeeva,

 -Original Message-
 From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] 
 Sent: 21 February 2011 09:18
 To: ofono@ofono.org
 Subject: [RFC] doc: Add support for CMAS/EU-Alert
 
 ---
  doc/cell-broadcast-api.txt |   26 +-
  1 files changed, 17 insertions(+), 9 deletions(-)
 
 diff --git a/doc/cell-broadcast-api.txt 
 b/doc/cell-broadcast-api.txt index 52618eb..71b2516 100644
 --- a/doc/cell-broadcast-api.txt
 +++ b/doc/cell-broadcast-api.txt
 @@ -36,19 +36,27 @@ Signals   PropertyChanged(string 
 name, variant value)
   Please note that base station name 
 broadcasts are
   handled by the NetworkRegistration interface.
  
 - EmergencyBroadcast(string text, dict properties)
 + WarningSystemBroadcast(string text, dict properties)
  
 - This signal is emitted whenever an ETWS 
 cell broadcast
 - is received.  The string text contains 
 contents of the
 - broadcast.  The dict is made up of the following
 - entries:
 - EmergencyType - string value, 
 possible values
 + This signal is emitted whenever an ETWS 
 or CMAS or
 + EU-Alert cell broadcast is received. 
 The string text
 + contains contents of the broadcast. The 
 dict is made
 + up of the following entries:
 + WarningType - string value, 
 possible values
   include: Earthquake,
   Tsunami,
   
 Earthquake+Tsunami,
 - Other
 - EmergencyAlert - boolean value 
 hinting whether
 - an extra 
 emergency indicator
 + 
 OtherEmergency,
 + Presidential,
 + Extreme,
 + Severe,
 + Advisory,
 + 
 ChildAbduction,
 + MonthlyTest,
 + Exercise
 +
 + WarningAlert - boolean value 
 hinting whether
 + an emergency indicator
   should be 
 activated (e.g.
   vibrate mode, 
 emergency alert
   mode.)

Is this WarningType really required on the App side ? 
Irrespective of the warning type, the emergency broadcast
message handling won't change on the apps side (i.e, its
going to be displayed immediately to the user). This can
be achieved by the old boolean variable EmergencyAlert only ?

BR,
Rajesh
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono


RE: [RFC] doc: Add support for CMAS/EU-Alert

2011-02-21 Thread Jeevaka.Badrappan
Hi Rajesh,

ofono-boun...@ofono.org wrote:
 Hi Jeeva,
 
 Is this WarningType really required on the App side ?
 Irrespective of the warning type, the emergency broadcast
 message handling won't change on the apps side (i.e, its
 going to be displayed immediately to the user). This can be
 achieved by the old boolean variable EmergencyAlert only ?
 

Its Popup property which is used for displaying the
messages immediately to the user. EmergencyAlert Property
is used to hint whether an emergency indicator(Vibration, emergency
tone)
should be activated.

Yes, agree that the WarningType is not really required. 
May be it was there for some reason. This RFC patch just extends
the existing EmergencyType property.

Regards,
Jeevaka 
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono