[jsr361-experts] some remarks
- From: Lampart Thomas <
- To: "
- Subject: [jsr361-experts] some remarks
- Date: Fri, 17 May 2013 17:16:59 +0200
- Accept-language: de-DE, en-US
- Acceptlanguage: de-DE, en-US
Dear speclead and experts,
Sorry that I missed our last calls due to holidays and business travel.
Here is some (first) feedback from my side.
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 ? 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 ?!
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
3.) Overview: PCM and MIDI should not be a must if media support is chosen.
Simple tone generation is often sufficient for many applications.
4.) Overview: handling of input (e.g. keypad) should not depend on the
presence of a display. Many applications have keys but no display.
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
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.
7.) javax.microedition.cellular: I assume that this is also an optional
package, right ?
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.
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 ?
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. 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. 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.
11.) javax.microedition.media: where is it ?
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.
Looking forward to some healthy discussions.