[jsr361-experts] Re: [jsr361-observers] PFD candidate upload
- From: Lampart Thomas <
- To: "
- Subject: [jsr361-experts] Re: [jsr361-observers] PFD candidate upload
- Date: Tue, 11 Feb 2014 10:53:29 +0100
- Accept-language: de-DE, en-US
- Acceptlanguage: de-DE, en-US
Very helpful. Thanks.
Now from looking at the diffs the following remarks/questions:
-in "installerrorcodes" you removed the extra data information in a couple of
error cases. This seems to be a drawback. Can you please explain why you
From: Volker Bauche
Sent: Montag, 10. Februar 2014 20:36
Subject: [jsr361-experts] Re: [jsr361-observers] PFD candidate upload
donÄt caring about what I said some hours ago :-) I have now created HTML
diffs between the lastest spec lead draft and the now published PFD candidate
draft similar to what Michael Lagally has done for JSR-360.
You can find the zip with the diff analysis in the expert goup area of the
JSR-361 page under jcp.org at
Hope this is helpful.
Best regards -
Am 10.02.2014 11:31, schrieb Volker Bauche:
> Hi Thomas,
> a created change log would not help much as it would not contain any
> other info as those you get from your html comparison.
> The reason is that there are a lot of changes in the files in total,
> but not all changes have the same relevance:
> - there are "real changes in the spec (like new methods, new
> parameters, added exceptions)
> - there is improvement of the class or method description where the
> javadoc was detected
> as not being comprehensive or where info (e.g. about the behavior in
> a sepcial situation)
> was missing
> - there are corrections of typos
> - there are changes done for all or many files for formal or legal
> reasons etc.
> The changes interesting for you are of course only those according to
> bullets 1 and 2.
> Therefore the best way to trace the relevant changes in the spec is
> the usage of JIRA tracking tool.
> As done already for the last updated version, I have added to the
> email a list of all relevant JIRA issues below. This list can be used
> as a change log and is much more useful than a created one.
> The list itself (as seen below) documents the relevant changes that
> have been done to the spec since the last published version.
> If you are interested in a particular change, you can open the related
> JIRA issue, which includes a complete description of the issue, a
> communication thread usually between myself and the issuer in case not
> everything was clear from the beginning, and at the end as a
> (closing/resolved) comment a description from my side what I have
> changed and where and why (and what not and why not if applicable).
> This is the way I track the changes also myself (I do not have all
> changes in my mind that I have made several weeks ago either :-) ) and
> it works well.
> If you need assistance with JIRA, you can contact me at any time.
> Hope this helps.
> Best regards -
> Am 10.02.2014 11:04, schrieb Lampart Thomas:
>> Hi Volker,
>> Thanks for the update and also the list of JIIRA items.
>> However I would like to point out one thing which also came up in the
>> last JSR360 expert group telco:
>> Its still extremely difficult to find and see the changes in the
>> spec. Comparing the html files also does not help much as there is a
>> difference in all files (at least the date).
>> The JSR360 speclead promised to check if there is any way to create a
>> complete change log. No feedback on this yet.
>> Nevertheless I would like to ask you for the same thing. Having a
>> complete change log or any means to compare the html docs in a way
>> showing only the real changes would be very helpful.
>> Looking forward to talking to the EG on Thursdays.
>> Best regards
>> -----Original Message-----
>> Sent: Samstag, 8. Februar 2014 10:20
>> Subject: [jsr361-observers] [jsr361-experts] PFD candidate upload
>> Dear experts,
>> I have uploaded the latest version of the spec being the candidate
>> for the Proposed Fonal Draft mid of February for review to the expert
>> group section of the JCP.org site of our JSR.
>> Since last version, many minor improvements have been done, like
>> changed parameter names, some changed methods, added missing
>> exceptions and improvements in the wording of class and method
>> The most significant change is the wording abou handling of
>> permissions for both, MEEP applications and legacy IMP-NG applications.
>> I will explain this change in an expert group meeting next week, see
>> invitation in separate email.
>> All changes are documented in the issue tracker, for a complete list
>> of changes, please have a look there:
>> For your convenience, here comes again a list of the relevant JIRA
>> issues that have been raised and resolved/closed since my last list:
>> MESPEC-2966 Player javadoc mentions STOPPED_AT_TIME, while there is
>> no such Event type
>> MESPEC-2959 Remove ActionsDeniedPermission
>> MESPEC-2957 Application Lifecycle "Active" State
>> javax.microedition.lui.Display.addDisplayListener(null|added listener)
>> MESPEC-2954 Spec clarification request: When PowerManagerException
>> with error code being KEEP_CURRENT_STATE may be thrown
>> MESPEC-2948 "Dependencies of optional MEEP 8 Components" table
>> needs corrections
>> MESPEC-2946 IMCProtocolPermission must always include <server name>
>> and <server value> for particular server
>> MESPEC-2945 MIDlet.platformRequest(String) exception clause is
>> MESPEC-2944 Add CellularNetwork.getByNetworkInterface method
>> MESPEC-2942 Section "Platform Default Character Encoding" should be
>> removed from MEEP spec or fixed
>> MESPEC-2939 microedition.profiles is mandated to not contain IMP-NG
>> MESPEC-2936 The javax.microedition.lui.Display colour method names
>> MESPEC-2935 javax.microedition.media.Manager is not final
>> MESPEC-2934 Provisioning needs clarification
>> MESPEC-2931 SWM: incorrect method name Suite.setSuiteState(.....)
>> MESPEC-2930 Synchronize installation error codes between SWM and
>> MESPEC-2929 Inconsistency in security for applications spec
>> MESPEC-2927 Event, EventPermission classes: Need to clarify the
>> non-acceptable values of "event name".
>> MESPEC-2923 Unexpected naming "CTLS" is in the "BNF for Parsing
>> Application Descriptors"
>> MESPEC-2922 SWM: TaskManager has method addStatusListener but adds
>> *TASK* listeners
>> MESPEC-2920 SWM: undefined behavior for TaskManager's
>> stop/pauseTask() methods
>> MESPEC-2918 SWM: Pausing a task contradiction
>> MESPEC-2917 SWM: Canonical way to detect whether the Suite is
>> already uninstalled/removed?
>> MESPEC-2916 SWM: What should happen when the app tries to uninstall
>> MESPEC-2915 SWM: Confusing sentence in SuiteManager.removeSuite()
>> MESPEC-2914 SWM: Javadoc for InstallErrorCodes contains
>> internal/non-relevant info.
>> MESPEC-2910 Unclear installation status code when MIDlet-Name and
>> LIBlet-Name provided both
>> MESPEC-2909 Impossible to request ssl server connection permission
>> via IMP-NG permission
>> Best regards -
>> This message and any attachments are intended solely for the
>> addressees and may contain confidential information. Any unauthorized
>> use or disclosure, either whole or partial, is prohibited.
>> E-mails are susceptible to alteration. Our company shall not be
>> liable for the message if altered, changed or falsified. If you are
>> not the intended recipient of this message, please delete it and
>> notify the sender.
>> Although all reasonable efforts have been made to keep this
>> transmission free from viruses, the sender will not be liable for
>> damages caused by a transmitted virus
This message and any attachments are intended solely for the addressees and
may contain confidential information. Any unauthorized use or disclosure,
either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for
the message if altered, changed or falsified. If you are not the intended
recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free
from viruses, the sender will not be liable for damages caused by a