Hi Thomas, all
@Thomas: Thanks for your valuable comments - pls. see my comments below inline.
@All: Pls. get sure to send your comment about your opinion about going to EDR.
There are two points you should consider:
- The question was whether I get your clearance to PREPARE EDR, this does not mean the current spec draft version should become the EDR version. This preparation does include of course to remove the TBD and TODO remarks still in the current version, update the pictures (class diagrams) not being up to date etc. - just to answer Thomas' claim below
- Of course Thomas' comments below will be taken into account before going to EDR.
If there are other comments, it would be good to have it soon in order to make some progress.
So I set a new deadline for your EDR yes/no comment (and other, content-related comments if any)
for Thursday, May 23 EOB.
If you feel we need another call to discuss other issues, e.g. on Thursday, pls. let me know asap.
Am 17.05.2013 17:16, schrieb Lampart Thomas:
" type="cite">Yes, many JSRs have javadocs only.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 ?
" type="cite">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.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 ?!
" type="cite">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).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 "> ."
" type="cite">Ok, we can soften this requirement accordingly.3.) Overview: PCM and MIDI should not be a must if media support is chosen. Simple tone generation is often sufficient for many applications.
@All: If you have an opinion about this point, pls. let me know.
" type="cite">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?)4.) Overview: handling of input (e.g. keypad) should not depend on the presence of a display. Many applications have keys but no display.
" type="cite">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.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
" type="cite">It does not overlap. The interactiopn between those two is well-defined.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.
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?
" type="cite">Yes, and it is declared as such. Where do you miss this information?7.) javax.microedition.cellular: I assume that this is also an optional package, right ?
" type="cite">Actually the more generic solution was inteded to ease the confusion. :-)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.
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.
" type="cite">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.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 ?
" type="cite">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.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.
" type="cite">The PowerManager allows to do so using the setPowerState method.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.
" type="cite">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.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.
" type="cite">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.11.) javax.microedition.media: where is it ?
" type="cite">Ok, will have a look at this again.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.
" type="cite">Looking forward to some healthy discussions. Kind regards Thomas
[jsr361-experts] Re: some remarks