JSR 135 Maintenance release change log


Maintenance lead : Lakshmi Dontamsetti, Aplix Corportion.
Email id : lakshmi@aplixcorp.com

Maintenance release version : From 1.2 to 1.3

Number Changes Reason Status
1
Add quality, colors, progressive, interlace and type as new keys for encoding format string.

quality is the quality parameter related to the format. E.g. in jpeg it would be the number 0 - 100 to specify the quality of the image.

colors tells the number of colors in the image, progressive tells if the image is progressive and interlace tells if the image is interlaced

type tells the type of the image. E.g. jpeg images can be encoded either as JFIF or EXIF so type can be used to specify which encoding is used.

Encoding parameters for the images in VideoControl.getSnapshot are not sufficient. It allows you only to specify the image as a png or jpeg image.

E.g. in case of PNG i'ts not possible to specify whether the image is wanted in grayscale, 256 colour indexed image or in full colour.

ACCEPTED

for 1.1

2 Specify explicitly in the documentation that unrecognized parameters in encoding strings will throw Exception.
Current specification is not clear what is the expected outcome if unrecognized parameters are used. Customized parameters are allowed but it's unspecified how they are treated in an implementation that doesn't recognize them.
ACCEPTED

for 1.1

3 Specify explicitly in the documentation that parameters in encoding strings that are recognized but contain a false value will throw Exception.
If additional parameters are taken in use with image encoding formats it is possible to require picture in formats that are not supported. In those cases Exception should be thrown. Otherwise the application doesn't have any way to tell if it got the image in the exactly required format.

E.g. if image is required with width and heigth that are not supported then MediaException should be thrown.

ACCEPTED

for 1.1

4 Specify tone sequence format as a file format. Suffix of a tone sequence file shall be .jts.
Tone sequence format is not fully specified as a file format. The structure and MIME type are specified but it's lacking the suffix of a file. If the format is going to be more widely used then the file suffix is needed in order to make the www servers to recognize the file and give it the correct MIME type for the transportation.

Since the format already has a MIME type, a Player can be created for tone sequence content by using InputStream and MIME type. In order to create a Player from locator, tone sequence must have a recognizable file suffix.

MIME type specification for tone sequence in Manager documentation doesn't clearly point to the tone sequence format specified in ToneControl.

ACCEPTED

for 1.1

5 Accept MIME types as formats in encoding strings.
Current specification has a limited set of formats that can be used for encoding. The specification is written in a way that prevents one from adding own formats. Making MIME types as acceptable encoding formats would let the implementations support any formats they like.
ACCEPTED

for 1.1

6 Document jpeg as the recommended format to be used in image capturing.
png is the default format for capture images. That's fine but the documentation should be rewritten to say that if the platform supports jpeg then application should use that instead because jpeg images require a lot less space than png images.
ACCEPTED

for 1.1

7 Add recommended security practices as part of the specification.
Implementors of MMAPI on top of MIDP 2.0 require recommended practices for security. Since MMAPI is an optional package the correct place for the practices is in the MMAPI documentation. It can be put right into documentation or delivered as a separate addendum together with the rest of the MMAPI documents.

The security practices also serves implementations on top of other profiles than MIDP 2.0.

ACCEPTED

for 1.1

8 Revise the GUIControl and VideoControl examples.
  1. USE_GUI_PRIMITIVE/ LCDUI + AWT example makes a double string in "new String("java.awt.Component")"
  2. In USE_DIRECT_VIDEO example some people read that canvas is passed as a null. It should be made clear that the Canvas is get somewhere before its used.
  3. Again in USE_DIRECT_VIDEO example the braces are missing. Even if vc is null it's still used a few lines later.
ACCEPTED

for 1.1

9
Documentation for GUIControl.initDisplayMode() method should clearly say that for different modes the arg contains objects of totally different type.

It's already said in the documentation that the semantics are different but it could still be said more clearly. ACCEPTED

for 1.1

10
Document that System.getProperty() method to query encodings returns strings that contain the "encoding=", or otherwise make it clear that the pieces of the string can be used as they are without the need to add anything to them.

RI already works like this but from reading the documentation it isn't obvious. ACCEPTED

for 1.1

11 Specify that VideoControl.getSnapshot is optional.
Even at the moment the implementation doesn't necessarily need to return an image from this method but the documentation should clearly say that it may not work with all formats. The primary need for the method was to support camera but for other visual content it's possible that snapshots are not supported.
ACCEPTED

for 1.1

12 Specify how the recording format is set when OutputStream is used.
If the recording is done by using a locator the format can be easily specified but the specification doesn't exactly tell how to do it when OutputStream is used. In that case the format is set when the Player that is recorded is created by locator where the format can be specified. Otherwise the recording format is the same as the input format.
ACCEPTED

for 1.1

13 Make RecordControl.setRecordStream to throw SecurityException. MMAPI security recommended practices require RecordControl.setRecordStream to throw an Exception. ACCEPTED

for 1.1

14 Specify a locator for radio. Specify a locator to create a Player for radio in given frequency. ACCEPTED

for 1.1

15 Clarify the low level audio streaming
Include a discussion on how MMAPI can be used as an interface for sending raw data to the audio device. Specifically, it relates to specifying a low level audio encoding for sending ("streaming") unbounded data to the audio device.
ACCEPTED

for 1.1

16 Clarify the behaviour during recording when the memory runs out During a recording session, if recording space ran out, implementation should auto commit the recorded data and send RECORD_STOPPED event ACCEPTED

for 1.1

17 Add query of the version of the MMAPI version implemented. The functionality of the maintenance release is slightly different from the MMAPI 1.0 so the application should be able to query the version of the MMAPI. ACCEPTED

for 1.1

18 Remove the requirement that VideoControl.getSnapshot supports at least PNG.
Originally PNG was required to guarantee that images are returned in some known format. PNG isn't really suitable to store photographs and otherwise there is no need for PNG decoder in implementations so keeping PNG as mandotory format would just be a burden for implementors.
ACCEPTED

for 1.1

19 Fix the ABNF presentation of the locator strings

video_params say that video_param parameters are separated by "&". But in the video_param definition it's said that video_param consists of 1* ( equals to 1..N) of the following parameters. Instead of 1..N parameters exactly one is needed.

Same error occurs also elsewhere in the locator documentation and must be corrected.

ACCEPTED

for 1.1

20 Address the CDC security in the specification

MMAPI 1.1 contains a security addendum to specify security permissions for implementations on top of MIDP. However, MMAPI is meant for all J2ME profiles not only for MIDP. Therefore, security considerations of MMAPI must be specified for CDC/CDC-based profiles as well.

Security addendum should speficically address CDC by specifying the java.lang.Permission based security permissions for MMAPI.

PROPOSED

for 1.2

21 Explicitly address MIDP 3.0 class-based permission model usage in MMAPI . The MMAPI 1.2 specification currently defines the expected handling of permissions for MMAPI on MIDP 2.0 and CDC implementations but does not allow or specify behavior for the new MIDP 3.0 class-based permission model. The specification should be updated to include behavior for MIDP 3.0 implementations.
PROPOSED

for 1.3
22 Place PlayerPermission class in the javax.microedition.media package.
The PlayerPermission class is placed in the top directory of the specification. It has to be placed in the right package javax.microedition.media.
PROPOSED

for 1.3
23 Include MIDP 3.0 in "Related Literature" section of  the Overview page.
MIDP 3.0 mandates JSR 135. Therefore, MIDP 3.0 should also be included in the "Related Literature" section.
PROPOSED

for 1.3
24 Remove the inaccurate status of JSR 118 in "Introduction" section of the Overview page.
The JSR 118 specification is completed. Hence, the MMAPI 1.2 version should remove "ongoing" in the phrase "The MMAPI Expert Group has also contributed to the ongoing JSR-118 (Mobile Information Device Profile 2.0) JCP specification, and the target is to make MMAPI a direct superset of the JSR-118 MIDP 2.0 Media API."
PROPOSED

for 1.3
25 Change the specification lead to "Aplix Corporation".
The specification lead of JSR 135 has changed from Nokia to Aplix Corporation.
PROPOSED

for 1.3
26
Place the description of  "Protocol and Content Agnostic" in the right column in "Feature" section of the Overview page.
The description of the "Protocol and Content Agnostic" feature has been placed in the wrong "Feature" column. PROPOSED

for 1.3
27 Remove the extra line in the description of "Extensible" entry in the "Feature" section of the Overview page.
The extra line is unnecessary  in the description of "Extensible" entry in the "Feature" section of the Overview page.
PROPOSED

for 1.3
28 Fix the typos for "audio.encodings" in the "System Properties" section of the Overview page.
The "System Properties" section has references to "audio.encoding", but it should refer to "audio.encodings".
PROPOSED

for 1.3
29 Fix the typos for "video.encodings" in the "System Properties" section of the Overview page.
The "System Properties" section has references to "video.encoding", but it should refer to "video.encodings".
PROPOSED

for 1.3
30 Fix the typos for "video.snapshot.encodings" in the "System Properties" section of the Overview page.
The "System Properties" section has references to "video.snapshot.encoding", but it should refer to "video.snapshot.encodings".
PROPOSED

for 1.3
31 Correct the mis-formatted html in "Tone Generation" section of the Overview page.
The "Tone Generation" section in Overview page has misplaced "nbsp". It should be removed.
PROPOSED

for 1.3
32 Correct the "should" and "must" reference in "Feature Sets" section in the Overview page with respect to the "Definitions" in the previous section.
The "Definitions" section in the Overview page has described the "term" and its "definition". Hence, all the "Must" and "Should" should be change to "MUST" and "SHOULD" in "Feature Sets" section according to the "Definition" section described above.
PROPOSED

for 1.3
33 Explicitly address that MIDP 3.0 mandates JSR 135.
MIDP 3.0 specification mandates JSR 135. Therefore, it should be explicitly specified in the specification.
PROPOSED

for 1.3
34 Remove the unnecessary code in "Scenario 10: Capture and Recording" in Overview page.
Thread.currentThread().sleep(5000)” should be “Thread.sleep(5000)”. Thread.sleep is a static method and should not be called on the object; anyway, sleep method already acts on the current thread so the call to currentThread is not necessary.
PROPOSED

for 1.3
35 Remove the unnecessary "extends java.lang.Object" in the DataSource class definition.
Since all classes in Java extends java.lang.Object, it is unnecessary to explicitly specify "extends java.lang.Object" in the DataSource class definition.
PROPOSED

for 1.3
36 Correct the term "overload" in the DataSource constructor. 
The constructor of the DataSource should be overridden by the subclasses instead of overloaded.
PROPOSED

for 1.3
37 Fix the typo in MediaException class.
Spec says “The error message string s can later be retrieved by the Throwable.getMessage() method of class java.lang.Throwable.” It should be “The error message string s can later be retrieved by the Throwable.getMessage() method of class java.lang.Throwable.”
PROPOSED

for 1.3
38 Fix the reference of getKeyValue in the MetaDataControl class.
In MetaDataControl.getKeyValue, the spec incorrectly refers to getKeyValues. It should refer to getKeyValue.
PROPOSED

for 1.3
39 Fix typo in Control class.
The phrase "The set of operations are is usually functionally related" is corrected as specified.
PROPOSED

for 1.3
40 Simplify playback example in the Player class.
The "Simple playback" example refers to methods that have not yet been discussed.
PROPOSED

for 1.3
41
As discussed in MSA 2, throw IllegalArgumentException in Player.setLoopCount() method, if media cannot be looped by the implementation.
Adopting the clarification from MSA 2. PROPOSED

for 1.3