Hi Volker, Roger, all,
@Roger: thanks for your explanation
@Volker: thanks for your feedback
I merged Volkers and Rogers replies into one mail.
Further comments from my side below.
Further comments from my side below. I also added two new issues (13. and 14.).
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 ;-)
You'll find it convenient. It's much easier than searching in a 100+ pages pdf document. :-)
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 accordingly.
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.
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 ?
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.
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.
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 now.
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. :-)
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.
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.
Roger> The event package enables two kinds of event that are not
I totally agree to such a usage of the Event API!! Unfortunately when looking at the spec this seems to be not the way it is used because
a) The PowerManager ended up as Event subpackage
b) There is a couple of predefined events which seem to be totally misplaced here, e.g.
a. Anything that is network/3G related should probably go into the cellular package or AccessPoint ?
b. Backlight feels very Display related
Its probably too easy to just throw some events into the events package instead of putting them into a specific API and into a proper listener. I suggest to really reduce the number of predefined events to a absolute minimum here, maybe really ONLY the SYSTEM_STATE_xxxx events for now.
Roger> For specific APIs, each API design should include listeners with event
I would say the “Power-API” clearly goes in this category and has nothing to do with the Event API, if I follow the philosophy which Roger described above.
And a big drawback probably also is that you do only have one type of callback functions ? What about parameters some event might have ?
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.
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 management.
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 ?!
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.
See my comment above to what Roger wrote.
A javax.microedition.power with the PowerManager and a PowerManagerListener would make far more sense to me.
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.
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.
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).
Now I am just wondering what the TCK for such an API will look like, if different implementation are allowed to use this API in very different ways. ;-)
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 setPowerState method.
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 :-) (see above).
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.
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.
OK, so far implementations could also pass the TCK without supporting suites. Just please don’t enforce this in the future.
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 using the
We can think about replacing the MUST by a SHOULD.
Yes, I completely understand the usefulness of this dependencies declaration in MEEP because of the huge number of optionality. I am just saying that IMP-NG (and probably also MIDP) worked pretty well without using the dependencies, so for backward compatibility please don’t enforce them now.
I am wondering, how to actually create these dependencies in an application descriptor in a consistent way ? Can e.g. Netbeans do this automatically ? Because if not that would be a problem for the application developer.
[jsr361-experts] Re: some remarks