| 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. |
- 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
|
| 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 |
