Skip to main content

[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.

Kind regards
   Thomas



[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
 
 
Close
loading
Please Confirm
Close