 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 211: Content Handler API
JCP version in use: 2.7 Java Specification Participation Agreement version in use: 2.0 Description: Enabling J2METM applications to handle multi-media and web content can give developers and users a seamless and integrated user environment on mobile phones and wireless devices. Please direct comments on this JSR to the Spec Lead(s) Team
NOTICE: Please be aware the CDC 1.0 specification initially related to this JSR has been replace (superseded) with the newer CDC 1.1 specification. CDC 1.0 will no longer be supported after 18-Aug-2009. This JSR and other optional technologies based on the CDC 1.0 standards are fully compatible with the CDC 1.1 standards. All development and certification efforts should be updated to use the current, supported technology. Original Java Specification Request (JSR)
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification Submitting Member: Sun Microsystems Name of Contact Person: Roger Riggs E-Mail Address: roger.riggs Telephone Number: +1 781 442 0539 Fax Number: +1 781 442 1610 Specification Lead: Roger Riggs E-Mail Address: roger.riggs Telephone Number: +1 781 442 0539 Fax Number: +1 781 442 1610 Initial Expert Group Membership: Motorola Supporting this JSR: Sun Section 2: Request
2.1 Please describe the proposed Specification:The purpose of this JSR is to define an optional package for an API and associated model permitting the invocation of J2ME Applications to handle actions on Uniform Resource Identifiers (URI) based on the MIME-type or scheme. For example, A MIDP MIDlet or a Personal Profile Xlet or main can be registered to handle a MIME type and appropriately display its content. The model will allow the application managment software of the device to control the execution of the applications to conserve resources and to enforce the security policy of the device and the Java runtime. The functions required are registration, launch based on a URI, and retrieving of resource parameters when launched. Registration allows a packaged J2ME application, for example a MIDlet in a MIDlet suite, to be associated with a type and be invoked from any application to handle a URI. One application can use the URI and/or MIME-type to invoke another application. The interactions between the invoking and invoked applications should allow the applications to run sequentially passing parameters and returning results and perhaps regaining control after the handler exits. Each application executes in the appropriate runtime. In a simple example, a game developer could make available new levels as links on a web page. The linked resource's MIME type would be used on the device to start the game and pass the URI. This provides seamless integration possibilities between browsers and applications. The link could be presented to the user in a message, in a browser, or from another application and the device software would dispatch the matching application. Registration attributes will be defined for application packaging to allow application installers and provisioning servers to correctly identify and register the application. This optional package will permit enhanced integration of J2ME applications into a device?s application environment; browsers and native applications as well a Java language applications will be able to invoke Java applications which dynamically extend the media types and capabilities supported by the device's application environment. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)The API and registration mechanisms will support both J2ME Profiles including the Mobile Information Device Profile (v2.0) using MIDlets and Personal Profile applications using main, Xlets, or Applets. 2.3 What need of the Java community will be addressed by the proposed specification?The intention of this JSR is to enhance the integration of J2ME applications with the capabilities of the J2ME-enabled device. 2.4 Why isn't this need met by existing specifications?None of the existing APIs within J2ME are addressing the proposed functionality. The MIDlet.platformRequest function of MIDP 2.0 does not provide for registration or passing the necessary parameters. There is no collorary in the CDC/Foundation or Personal Profiles. The Java Activation Framework for J2SE (JAF) provides a binding of MIME-types and JavaBeans along with robust data flavor, data handlers, datasource, and Transferable support that are unnecessary and not supportable by CLDC based profiles. 2.5 Please give a short description of the underlying technology or technologies:Please see 2.1 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)TBD 2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?This request allows the device to control the registration, storage and execution resources needed to support the API. 2.8 Are there any security issues that cannot be addressed by the current security model?No, this API will use the security model of the device as necessary to protect restricted resources. 2.9 Are there any internationalization or localization issues?No 2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No 2.11 Please describe the anticipated schedule for the development of this specification.It should be possible to complete this API specification in a reasonable time (6-9 months) since it is narrowly scoped and it will build on the previous work using vendor specific APIs and experience. 2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.It is anticipated that a combination of email discussion, feedback on regular drafts, conference calls and face-to-face meetings will work well. 2.13 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.The RI will leverage the MIDP 2.0 Reference Implementation. As an optional package the TCK can be delivered as a standalone product. 2.14 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).N/A 2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.Sun will make the the TCK and RI available for license separately:
Section 3: Contributions
3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available. * JSR 30: Connected, Limited Device Configuration Specification (CLDC) 3.2 Explanation of how these items might be used as a starting point for the work.The base configuration and profile documents provide the framework in which the Content Handler API must operate including interactions with the MIDP Over The Air installation and Application Management Software and packaging specifications for MIDP and corresponding application model for Personal Profile. Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.The proposed specification is not intended to address any aspect of management of content on the device related to the storage of or access to content (for example DRM). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
