thanks a lot for your quick replay.
Pls. find my comments inline.
Am 21.05.2013 16:38, schrieb Lampart Thomas:
thanks for your feedback. Yes, please prepare the EDR!
You'll find it convenient. It's much easier than searching in a 100+
pages pdf document. :-)
comments from my side below. I also added two new issues
(13. and 14.).
Am 17.05.2013 17:16, schrieb Lampart Thomas:
1.) General: I am a bit surprised that there is no pdf available, just the Java docs. Is this the current style to do JSR specs ?
Yes, many JSRs have javadocs only.
If so then maybe the document structure needs some attention as I feel it is not so easy to actually read through the document. Where to start and where to end ?!
The start is the overview file. In the
beginning, it has a list of (links to the) essential chapters
being part of the spec. You can read them one by one. The APIs
themselves can be accessed even more convenient in this form
if you choose the frame presentation of the javadocs (compared
to a "linear" pdf document). Then you have a field to your
left listing all the packages and classes and you can navigate
directly to the API you would like to read.
OK. But I still have to make sure to not
miss any links in order to not miss any part of the
“document”. Trying to get used to it ;-)
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.
2.) Overview: There is a bunch of TBDs and TODOs in the spec. Some of them should probably do not need to be tbd anymore ?! e.g.:
"The preferred forum for comments will be TBD.
Alternatively, comments may be sent to
Yes, you are right of course. These TBD
should be mostly obsolete in the meantime. I'll go through it
in preparation of EDR (see above).
3.) Overview: PCM and MIDI should not be a must if media support is chosen. Simple tone generation is often sufficient for many applications.
Ok, we can soften this requirement
@All: If you have an opinion about this point, pls. let me
OK. that would be good.
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
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
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 don't think so. The more generic concept is necessary as we have
to handle a much broader variety of events than we used to have in
IMP-NG times. We can check whether there is a way to somehow group
the event inorder to make the concept more comprehensive.
5.) General: It would be useful to denote the optional classes also in the class description. This way the reader could get a clearer picture which classes might not be there at all in a device
Optionality is package based. Means an API
is implemented or not (while dependency between APIs has to be
taken into account). Once a package become part of the
implementation, all classes in this package MUST be
implemented (at least in a "dummy" mode). Optinality on class
level is inpracticable.
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?
7.) javax.microedition.cellular: I assume that this is also an optional package, right ?
Yes, and it is declared as such. Where do
you miss this information?
Optionality on package level is clear
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.
I understand the idea now, still I don’t
like it. I think this (certainly growing) list of events of
all different sorts IS confusing.
There are much better possibilities to transport parameters and
other information in this concept. The callback function accepts a
parameter of type Event. In this event object an unlimited number of
info can be transported. By checking the API again in order to write
this answer, I got aware that I've mixed up the "message and
information object" each event has with it's source (this happened
as a side effect of making the Event class a subclass of
java.util.EventObject from CLDC-8. I'll correct this and send out a
new spec version soon.
And a big drawback probably also is that
you do only have one type of callback functions ? What about
parameters some event might have ?
No. The reason why power management has an extra package is that it
includes some additional functionality like the PowerManager, and an
implementation that uses events but is not interested in power
management should have the chance to implement the event mechanism
without the whole power mangement it won't need.
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 ?
See above. The whole power management has
to parts: handling of (power management related) events - it
seems to be a logical consequence to insert this part into the
general event concept. And the power manager to actively
receive informations and perform settings for the power
This architecture still feels very
strange to me. Especially when I envision where this is
supposed to end up. We will have various functionalities as
javax.microedition.event.xxxx just because this
functionalities uses some events ?!
In general, all kinds of events can be handled just with the event
As a matter of fact, you have this. It is just a subpackage of the
event package because it uses the event mechanism for power events.
A javax.microedition.power with the
PowerManager and a PowerManagerListener would make far more
sense to me.
Well, the API will be unique for all devices. What a single state
means for a certain device is very hardware-dependent, so it will be
difficult to rule a unique definition of the states for all
platforms. A good example is your own retention against
POWER_STATE_REGULATED_LOW_POWER below. For your devices it may make
no sense, for others it is very important. The little miracle we
have to create with this profile is it to create an API everyone in
this very heterogeneous field can live with. The solution can only
be a good balance of ruling (e.g. by determining classes and methods
with fixed signatures) and some degrees of freedom (like the
interpretation what such a state in particular means).
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.
This is a question of implementation. The
system could use the notification in order to ANNOUNCE it is
going to sleep and wait long enough to give the application
receiving the notification to still display a message "Going
to sleep" or something.
Yes and No ;-) Of course as long as the
events are not clearly defined any implementation can do
(implement) whatever it wants. But if we want to handle it
this way why having a standard API at all ? Everybody who
needs this can implement its own API as it fits. My
understanding of a standard API would be that we have a
clearly defined (subset) of power management which can then
be implemented on various devices in the exactly same way.
As a consequence, one implementer can decide, that going to "SLEEP"
mode allows some delay in order to give an application the chance to
display a message to a user, while another one (e.g. one without any
display) does not need this display and just goes to sleep.
And you can implement "POWER_STATE_REGULATED_LOW_POWER" the same way
as "POWER_STATE_FULL_POWER" as it makes no difference in your
implementation (and POWER_STATE_REGULATED_LOW_POWER will probably
never be checked for in your applications), while another
implementation may emphasize the difference between sthose states.
Yes :-) (see above).
Actually choosing a state might be more important for a midlet than getting reports. After all the midlet is the master in many application, so it tells the system what to do.
The PowerManager allows to do so using the
Btw. Where do these defined power states (e.g. POWER_STATE_REGULATED_LOW_POWER) come from ? I think we will need some further discussion here.
Those states have been created after
evaluating the requests from many different potential users of
the API. Not all states may have a meaning for any device.
See above. Is this a good idea for a
standard API ?
Yes, there have been indeed plans to remove suites. The main issue
with this was backward compatibility with IMP(-NG) and the
consequences for the security framework. Your implementors will love
the MEEP EG for keeping suites as this way they can use the
implementation model they have once done for IMP-NG without changes.
11.) javax.microedition.media: where is it ?
The intention is to point here to a defined
audio subset of JSR-135. THis is still under clarification. In
caser this makes problems, the definiton of the audio
subpackage will be copied from JSR-135 into this spec (as it
has been done for IMP-NG). In any case the definition is
identical to the audio subpackage of JSR-135.
OK. IMP-NG audio package is fine.
12.) Application Provisioning: Whats the UAProf good for ? Please make it optional if someone really needs this. For device identification its often sufficient to put something meaningful in the "User-Agent" field.
Ok, will have a look at this again.
13.) I remember a discussion
with Oracle some time ago if and why we need “suites”. I see
the suites are still there. Isn’t one application per .jar
enough ? Do we really need them ? I don’t think so.
An implementation that will in general have only one application per
jar has no significant overhead with suites (as a suite can of
course also conisit of only one application), others that want use
advantages like the common access to one RMS by several applications
within a suite can still use it.
We can think about replacing the MUST by a SHOULD.
14.) a question about
optionality and compatibility: on the “optionality and
compatibility” page of the spec it says several times: “Applications
requiring the implementation of the xxxx optional package
in order to be able to run, MUST declare this request
MIDlet-Dependency-”. Now when I think about an
IMP-NG application as it is, this application would not have
this attribute. Still it could be able to run IF my MEEP
implementation is IMP-NG compliant. So is my assumption
correct that these MUSTs in respect to attributes is only
true if my MicroEdition-Profile attribute of the application
descriptor says “MEEP-1.0”. If this attribute says IMP-NG
the MEEP implementation would behave differently and either
accept the midlet if it is IMP-NG compliant or reject it,
but not check any dependencies attributes, right ?
If you look at MIDP, there is the MIDlet-Dependency-<n>
attribute used in order to declare dependency of certain external
JSRs such as JSR-120. An application should declare this dependency
as this makes sure that it is only installed if the device
implements JSR-120. As far as I know, the applications also installs
and runs fine without this attribute AS LONG AS JSR-120 is defined.
Otherwise, it will crash with a ClassNotFoundException or something
unapprpriate (I'll doublecheck this).
The dependency names for the optional packages had to be introduced
because due to the optionality it is not a-priori clear whether a
certain packae is available for an implementation or not. An
implementation that claims to be backwar compatible to IMP-NG has of
course to implement at least all packages being mandatory in IMP-NG
(see the chapter about Profile Sets), and then all IMP-NG MIDlets
should work fine.