Skip to main content

[jsr361-observers] [jsr361-experts] Re: some remarks

  • From: Volker Bauche < >
  • To:
  • Subject: [jsr361-observers] [jsr361-experts] Re: some remarks
  • Date: Thu, 11 Jul 2013 18:17:31 +0200
  • List-id: <jsr361-experts.jsr361.java.net>

Hi Thomas,

see inline.

Thanks -
Volker

Am 11.07.2013 18:02, schrieb Lampart Thomas:

Dear specleads and experts,

As discussed in our call today I check my input below against the latest version of the spec and I found most of it in it. Thanks.

Just a few additional remarks:

1.)You didn't want to add "isLimited" ? why?

@Roger: Could you have a look, pls.?

2.)Oh and you added some network types to "getNetworkType". I believe this was also part of our discussion today. I didn't suggest to add 802.11. Don't know where this came from ;-)

Right, looks that this came from somewhere else. :-)
Anyway, we will remove this.

I also believe that you can remove CSD.  Don't know what this would be.

Circuit Switched Data, the original form of data transmission that has been developed for TDMA based mobile phone systems like GSM.
It's 3GPP.

3.)Regarding my suggestions for the Power API. I didn't find of these in the spec. What are your current thoughts on these issues ?

Sorry, looks like have missed this in your email below. I'll have a look.

Kind regards

Thomas

*From:*Lampart Thomas
*Sent:* Freitag, 24. Mai 2013 16:43
*To:* 
' '
*Subject:* [jsr361-experts] Re: some remarks

Hi Volker, all,

@Volker: thanks for the spec update.

As promised here is some input regarding extending the cellular package. I really tried to focus on basic functionality, as managing a cellular device can sometimes really involve a lot of things. I am writing this from the perspective of a 3GPP cellular, so someone who is familiar with CDMA might want to recheck this and make a suggestion how these functionalities can be more generalized to cover both technologies.

1.)Subscriber class:

a.Authentication code handling (e.g. sim pin): Suggestion:

i.Add method: "setAuthenticationCode (String code)"

ii.Add method: "AuthState getAuthenticationState ()"; states are : READY, PIN, PIN2, blocked

2.)CellularNetwork class:

a.Add method: "static CellularNetwork[] getAvailableCellularNetworks()", returns all cellular networks the device can see

b.Add method: "static selectNetwork (CellularNetwork network)", selects a network; and "static selectNetwork ()" for automatic network selection

c.Add method: "deRegister()"; deregisters from cellular network, the device will not automatically register again even in automatic mode.

d. Add the following method: "int getAvailability()", gets network availability, possible values are: unknown, current operator, available, forbidden

e.Add the following method: "boolean isLimited()", indicates limited service, i.e. device is camping on a network but cant register

f.The network type should not only distinguish between 3GPP and CDMA but should also support subtypes like GSM, UTRAN, GSM with EGPRS, UTRAN with HSDPA, UTRAN with HSDPA and HSUPA

Also one additional remark regarding the Power API. I suggest to add the following functionality into the PowerManager:

·Switch off device

·Reboot the device

·Disable/Enable all RF ("Airplane mode")

Kind regards

Thomas

*From:*Volker Bauche 
[mailto: ]
*Sent:* Freitag, 24. Mai 2013 02:50
*To:* <mailto: >
*Subject:* [jsr361-experts] Re: some remarks

Dear experts,

in order to accelerate the discussion a bit, I had a phone call with Thomas today about the
issues we have discussed in this thread and that had not been solved during this discussion
so far.
This email documents our findings (see red inline below).
I have also uploaded a new spec version (v.0.5) to the JCP site (EG area) that reflects
the findings explained below (with the exception of the additional methods for the Cellular
package, where I have to wait for Thomas' list (see below).

Although not all of you have sent me a vote about preparation of EDR, I assume
that those of you that did not do not have serious concerns against this, so I will
prepare this step now. The EDR version will be very close to the v0.5 I have just
uploaded, but I will let you know of course as soon as I have applied for EDR.

Best regards -
Volker

        4.) Overview: handling of input (e.g. keypad) should not depend on 
the presence of a display. Many applications have keys but no display.

        How should the input from the keys be handled then? (I mean
        based on which API? Does it mean we need an API for processing
        key inputs independent on a graphical API?)

        *Well, the KeyListener doesn't look too bad to me. The problem
        with it is that it is in the same package as Display, right ?
        Or are there other dependencies ?*

        Yes, the key listener is part of the lui package. The package
        is not bug, the largest part is of course the Display class.
        If you find it acceptable to implement the lui package (with a
        then even smaller dummy Display class) for having an API to
        handle key events. we can keep it this way. If not, we will
        have to find a way to extract the key functionality from this
        package.
        Alternatives would be to put it into the event package (but my
        guess is that you would not like this - see below :-) ) or
        have an extra package for it.

        *I do not have a problem to implement a dummy Display class in
        order to use keys only. I am only a bit unsure how this would
        work for a TCK. As optionality is on package level only a TCK
        would probably expect a full implementation of the lui package
        or nothing at all, right ?*

    Right, while the question is, what means a "full implementation".
    You can do a dummy implementation that does nothing useful e.g. in
    the DIsplay class if you do not have a display, and hence pass the
    TCK if this implementation behaves as expected. The question is
    whether you want to do this, or if you would rather like to spare
    the memory. In this case we would have to extract the key handling
    from the lui package.

As it makes sense to have device with keys, but without a display, while it does not appear useful to have to implement
the whole lui package for that (which would be a dummy implementation anyway if there is no display), we have decided
to split the lui package: the KeyListener gets its own package javax.microedition.key, everything else remains in lui.


    6.) javax.microedition.cellular: I do have the feeling that this package 
somehow overlaps with the AccessPoint in CLDC8/GCF. Please clarify how these 
two function complexes interact and why they are separated in this way.

    It does not overlap. The interactiopn between those two is
    well-defined.
    But we have Roger as one of the CLDC Specleads in our EG.
    @Roger: Could you explain the interaction between AcceddPoint and
    Cellular to the EG a bit, pls?

    *Yes, please.
    Roger>* For the question about the relationship between CLDC
    AccessPoint and
    MEEP CellularNetwork.

    The AccessPoint abstration is focused onTCP/IP network interfaces.
    Its origin was based on the operating system or device managing
    the underlying networking stack.  The application can pick an
    interface
    and may want/need to be aware of its characteristics but cannot
    control it.
    Recent suggestions/improvements have expanded that somewhat but it
    is still primarily an abstraction for a networking stack.

    The MEEP CellularNetwork and Subscriber encapsulate information about
    wide area networking and the operator managed subscriber information
    found on SIM cards.  These abstractions provide access to cellular
    networking
    properties and controls.  As above, the application needs only an
    abstraction
    for the network and (mostly) leaves the management of the cellular
    network to
    the implementation.

    Most applications can operate effectively with only the
    AccessPoint information
    and do not need control over cellular functions in most cases and the
    separation makes the API easier to understand and use.

    *OK, thanks for clarification.*

    *Then one remark about the cellular package (in fact it's a
    similar remark as I had about the AccessPoint):*

    *This is an API which does only allow to query information which
    is in the device. It does not allow the midlet to configure or
    control anything. I think this is a big drawback!*

    *In a typical (M2M) device the Java application (midlet) is the
    master. There is nothing outside which could do this job. So e.g.
    who enters the sim pin code ? Who selects the network ? I think
    that this API should be able to do so.*

So would you mind providing a list of methods you miss?

Thomas volunteered to send a list with setter methods he would like to see in this package.

    **

    8.) javax.microedition.event: A general question about this package: why 
such a generic event package ?

        In the past several classes had some listener functionality and they received 
"their" events through this listener.

        To me it seems a bit confusing to have such a generic event mechanism 
which then again contains events of all sorts.

In order to make the API more comprehensive, we try the following: while several packages continue to use the event package in order to handle
certain events (means the Event and EventListener class that have been defined there), we move the package specific event names and values
into the respective packages: backlight stuff into lui.Display class, power and battery related events into the power package, data network related events into the cellular package.


    9.) javax.microedition.event.power: the previous question leads directly 
to this question: wouldn't it be nicer to have

        PowerManager class with a Listener instead of PowerManager being a 
part of an event package ?

        For me this just seems to be the wrong way around ?

The solution described above includes also one for this issue.


    10.) PowerManager: good idea to have such a class, but at least for the 
use cases I know there are some issues here.

        E.g. a device can never signal a sleep state to a midlet, because the 
moment it would do so the device can not be in

        sleep state.

I'll clarify with our TCK guys how tests for certain power states will be performed in order to handle two concerns:
- WIll an implementation that initiates the SLEEP mode on a very low level - causing to fall into sleep immeditely and don't having the chance to send this event notification - have the chance to pass the TCK?
- How will the TCK handle the fact that an implementation may not handle all power states as they are not supported on a hardware level (like regulated low power state etc.)


Also: the passage in the spec reading that dependency attributes MUST be part of the JAD/Manifest if an application needs certain optional packages of MEEP in order to be able to run, was wrong and has been corrected.
As in MIDP and IMP(-NG), those Dependency attributes remain optional (also for optioanl packages), it is just recommended to use them in order to avoid that an application using a not implemented package will be installed and later crash during runtime.
But in cases where the manufacturer is the author of both, MEEP implementation and applications (a typical situation in the embedded world), this is of course not necessary.




[jsr361-observers] [jsr361-experts] Re: some remarks

Lampart Thomas 07/11/2013

[jsr361-observers] [jsr361-experts] Re: some remarks

Volker Bauche 07/11/2013
 
 
Close
loading
Please Confirm
Close