||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.
|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.||Proposed|
|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.
|4||Specify tone sequence format as a file format.
Suffix of a tone sequence file shall be
||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.
|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.||Proposed|
|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.||Proposed|
|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.
|8||Revise the GUIControl and VideoControl examples.||
|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.||Proposed|
|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.||Proposed|
|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.||Proposed|
|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.||Proposed|
|13||Make RecordControl.setRecordStream to throw SecurityException.||MMAPI security recommended practices require RecordControl.setRecordStream to throw an Exception.||Proposed|
|14||Specify a locator for radio.||Specify a locator to create a Player for radio in given frequency.||Proposed|
|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.||Proposed|
|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||Proposed|
|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.||Proposed|
|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.||Proposed|
|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.