JSR-135 Maintenance Release Change Log

Updated 8-Feb-2006

Number Change Reasoning 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