RE: [RFC PATCH] stk: add support of next action for menu

2010-12-13 Thread Lucas, GuillaumeX
Hi Denis,

 -Original Message-
 From: Denis Kenzior [mailto:denk...@gmail.com]
 Sent: Friday, December 10, 2010 6:00 PM
 To: ofono@ofono.org
 Cc: Lucas, GuillaumeX
 Subject: Re: [RFC PATCH] stk: add support of next action for menu
 
 Hi Guillaume,
 
 On 12/09/2010 07:00 AM, Lucas, GuillaumeX wrote:
  From: Guillaume Lucas guillaumex.lu...@intel.com
 
  According to the 3GPP 31.124 the support of next action
  in SIM toolkit menus is mandatory.
  ---
   doc/stk-api.txt|5 +++--
   src/stk.c  |6 ++
   src/stkagent.c |6 --
   src/stkagent.h |1 +
   test/test-stk-menu |6 +++---
   5 files changed, 17 insertions(+), 7 deletions(-)
 
  diff --git a/doc/stk-api.txt b/doc/stk-api.txt
  index 79daee6..f5bcae4 100644
  --- a/doc/stk-api.txt
  +++ b/doc/stk-api.txt
  @@ -66,13 +66,14 @@ Properties  string IdleModeText [readonly]
  Contains the identifier of the icon accompanying
  the idle mode text.
 
  -   array{struct{string, byte}} MainMenu [readonly]
  +   array{struct{string, byte, byte}} MainMenu [readonly]
 
 Can you tell me exactly what this can be used for?  What is the usecase
 for the application to know this information?
 

The next action is an indicator added for each item of a STK menu. It is to 
allow the terminal to indicate to the user the consequences of performing the 
selection of an item. I confess that I've never seen use of this option in a 
real STK application yet.

According to the applicability table (chapter 3.4) of the SATK conformance 
specification (3GPP TS 31.124) the support of the next action indicator is 
mandatory. Chapters 27.22.4.8.3 and 27.22.4.9.2 are the ones relative to the 
test of this feature.

Regards,
Guillaume
-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: Les Montalets- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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


Re: [PATCH 3/5] cdma-atmodem: Add CDMA MO Call Support

2010-12-13 Thread Dara Spieker-Doyle
Hi Denis

On Fri, 2010-12-10 at 22:41 +0100, Spieker-Doyle Dara
(Nokia-MS/SanDiego) wrote:
 Hi Denis
 
 On Thu, 2010-12-09 at 09:43 +0100, ext Denis Kenzior wrote:
 
  
drivers/cdma-atmodem/atutil.c|   45 +
drivers/cdma-atmodem/atutil.h|   65 +
  
  Are these verbatim copies of atmodem/atutil.[ch]?  If so, then there's
  no reason why you can't re-use those.  No need to copy them.
 
 No, they are not verbatim copies as e.g. error decoding is different.
 Would you prefer we clarify this by renaming the files cdmautil.(ch)?
 
On second thoughts, I agree for this patch - I will correct this and
re-use the drivers/atmodem/atutil.[ch].
Additionally, for future feature support, I do envisage some delta with
various AT utilities for CDMA. For example, with our current hardware,
the AT return string can have a different format from the GSM AT command
standard. 
Do you have any particular preference in such cases as to whether we
modify the e.g. gatchat sources directly to support this or whether we
create CDMA specific functions within the cdma-atmodem driver?

Thank you
Dara


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