| 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.
|
- USE_GUI_PRIMITIVE/ LCDUI + AWT example makes a double string in "new
String("java.awt.Component")"
- 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.
- 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
|
