Skip to main content

[jsr361-experts] Re: some remarks

  • From: roger riggs < >
  • To:
  • Subject: [jsr361-experts] Re: some remarks
  • Date: Tue, 21 May 2013 13:12:02 -0400
  • Organization: Oracle Corporation

" type="cite">
" type="cite">
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.

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.

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. 

Actually the more generic solution was inteded to ease the confusion. :-)
We have a lot of events to be handled, and it makes sense to handle them in a unified way. The listener concept is still there, it has just made more generic, also in order to keep the way open for future extension.

Roger> The event package enables two kinds of event that are not
specific to an API, those from the system, like startup and shutdown
events and events between applications.  Being able to send events between
applications was a key element of supporting robust applications that
could be isolated and still communicate.

For specific APIs, each API design should include listeners with event
types and parameters specific to the API. It improves usability and robust
uses.  The general event mechanism should only be used when a specific
API is not practical.


[jsr361-experts] Minor update to spec

volker.bauche 05/16/2013

[jsr361-experts] Re: Minor update to spec

Kimmo Löytänä 05/16/2013

[jsr361-experts] some remarks

Lampart Thomas 05/17/2013

[jsr361-experts] Re: some remarks

Volker Bauche 05/21/2013

[jsr361-experts] Re: some remarks

Lampart Thomas 05/21/2013

[jsr361-experts] Re: some remarks

Volker Bauche 05/21/2013

[jsr361-experts] Re: some remarks

roger riggs 05/21/2013

[jsr361-experts] Re: some remarks

Lampart Thomas 05/22/2013

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

Werner Keil 05/22/2013

[jsr361-experts] Re: some remarks

Volker Bauche 05/22/2013

[jsr361-experts] Re: some remarks

Volker Bauche 05/24/2013

[jsr361-experts] Re: some remarks

Lampart Thomas 05/24/2013

[jsr361-experts] EDR Application

Volker Bauche 05/24/2013
Please Confirm