From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: STK DisplayText changes proposal
Date: Tue, 23 Nov 2010 11:08:16 -0600 [thread overview]
Message-ID: <4CEBF500.1000607@gmail.com> (raw)
In-Reply-To: <AANLkTink8S-MHkHa+L1p4qxSLKub1nn0GYSYcVWYMVXX@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2391 bytes --]
Hi Andrew,
On 11/23/2010 10:55 AM, Andrzej Zaborowski wrote:
> Hi,
>
> On 23 November 2010 17:05, Denis Kenzior <denkenz@gmail.com> wrote:
>> On 11/23/2010 09:33 AM, Lucas, GuillaumeX wrote:
>>> Hi,
>>>
>>> According to the 3GPP specifications there is some missing points in the SATK DisplayText implementation and I want to propose some API changes here.
>>>
>>> 1. clear message after delay / wait for user to clear flag
>>>
>>> This flag corresponds to the bit 8 of the command qualifier (see ETSI TS 102 223) and indicates how the message should be cleared by the UI.
>>> In the STK agent documentation it's indicated that this flag is handled using different timeout value for the Agent DisplayText method call. But that doesn't seem the case in the code: there is no check of the flag.
>>
>> Andrew has to answer this one, it seems like there's a disconnect
>> between the implementation and the docs. Probably just a bug.
>
> It was in my first proposal, however the decision made here on the
> list or on IRC (I don't remember) was to remove all the details from
> the specification until there's a specific use case for them from UI
> authors. The current API is greatly simplified compared to TS 102.223
> on the basis that some of the parameters are never used by SIM
> manufacturers. This includes for example the "help available"
> information in the commands, the return values like "help requested",
> "icon could not be displayed", "screen busy" and many other bits. On
The help stuff is fully pointless, so we definitely won't be supporting
that one.
> one hand this makes sense but on the other I don't see it as a huge
> saving as long a we design the API in such a way that the unneeded
> call parameters or return values can be ignored by the UI writer. I
> have to point out that you were the advocate for simplifying the API
> to the minimum level needed to implement the iPhone STK app :)
Oh I still am ;)
>
> As for the clear after delay flag, there's a check for it in
> display_text_cb (line 1248). As far as I can make out the only
> difference is the response sent to the SIM.
So it has been a long time since those discussions, but it does seem to
me that using a higher timeout in the case of 'wait_for_user' flag seems
like a good idea. Do you remember why we left this out?
Regards,
-Denis
next prev parent reply other threads:[~2010-11-23 17:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-23 15:33 STK DisplayText changes proposal Lucas, GuillaumeX
2010-11-23 16:05 ` Denis Kenzior
2010-11-23 16:55 ` Andrzej Zaborowski
2010-11-23 17:08 ` Denis Kenzior [this message]
2010-11-23 23:29 ` Andrzej Zaborowski
2010-11-24 8:00 ` Lucas, GuillaumeX
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CEBF500.1000607@gmail.com \
--to=denkenz@gmail.com \
--cc=ofono@ofono.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.