 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 357: Social Media API
Reason: This JSR was not approved by the SE/EE Executive Committee in the JSR Approval Ballot. JCP version in use: 2.8 Java Specification Participation Agreement version in use: 2.0 Description: This specification proposes an API for accessing and providing social information networks Expert Group Transparency: Public Communications Issue Tracking Team
This JSR has been Rejected
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Werner Keil Name of Contact Person: Werner Keil E-Mail Address: java-social Telephone Number: +49 176 36954273 Fax Number: - Specification Leads: Werner Keil, Antoine Sabot-Durand E-Mail Address: java-social Telephone Number: +49 176 36954273 Fax Number: - Initial Expert Group Membership: Werner Keil Supporting this JSR:
CoreMedia AG Section 2: Request
2.1 Please describe the proposed Specification:
This specification proposes to provide an API for accessing social information networks, both Public (Facebook, Twitter, Google+, LinkedIn, Xing, Yammer,...) and Corporate, e.g. within the Enterprise or Institution (University, Hospital, etc.) 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)Desktop, Server, Mobile 2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.While this is primarily targeted at Java SE, it is particularly useful in a Java EE environment, especially when related to other EE technologies such as CDI. Further, it helps enhance Java EE making it more cloud-friendly by providing standardized access to public social networks. Corporate social networks are commonly used along with Java EE, Portals, or any highly scalable configuration. 2.4 Should this JSR be voted on by both Executive Committees?No. It should be voted on by the Java SE / EE Executive Committee only. At least until the merge of two separate Executive Committees is effective. 2.5 What need of the Java community will be addressed by the proposed specification?A social network is a social structure made up of individuals (or organizations) called "nodes", which are connected by one or more specific types of interdependency, such as friendship, kinship, common interest, financial exchange, dislike, cultural relationships, or relationships of beliefs, knowledge or prestige. This JSR provides a standard API for accessing and working with social networks. Except one (probably the least succesful) case, every major social network's existence is a result of using Open Source technologies. Many of those are based on Java or other JVM-based languages like Scala, Clojure, etc. 2.6 Why isn't this need met by existing specifications?>> The closest specification is probably Open Social, with various implementations like Apache Shindig or Spring Social. However, most of these built on top of quasi-standards or proprietary technologies adding the risk of a vendor lock-in even if the API itself may be provided Free or Open Source. Apache Shindig has been contributed by Google, but the project has not seen a lot of activity in recent years, unlike the most common social networks. It is said to be RI for Open Social 0.8.x and 0.9.x, but Google also released an Open Social Java Client on Google Code. Neither of them use Java (EE) standards like CDI or JSR 330, instead frameworks like Guice are used directly. While Shindig tends to separate model and implementation, and e.g. for Persistence even uses JPA, the Google version lacks both. It also puts a strong emphasis on MySpace which increasingly lost users to other services. Other examples like Ning API for Java also haven't exceeded OpenSocial 0.8.x as of now. Beside Shindig, 2 other projects, DeltaSpike and Rave were recently added to the Incubator. There are W3C discussion groups like http://www.w3.org/community/socbizcg/ or http://www.w3.org/community/fedsocweb/ While not directly related to the Java platform, communication with some of these groups seems a good idea, and at least one initial EG member has confirmed somebody joined on their behalf. 2.7 Please give a short description of the underlying technology or technologies:This specification should use well-established Java APIs like CDI, RESTful Web Services, Java Identity (JSR 351), JSON (JSR 353) or WebSockets (JSR 356) Beside those selected other JSRs being part of Java EE 7 and EE 6 (JSR 316) are considered, e.g. JMS (in relation to Social Messaging) or JPA allowing to leverate Social Query languages like SNQL, YQL or Facebook's FQL. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)javax.social or under java.net.social. 2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No 2.10 Are there any security issues that cannot be addressed by the current security model?No. It will build on Java Security APIs, especially those within Java SE/EE. Possible exceptions are security and authentication mechanisms used in Social Media, like OAuth or OpenID, which may in some cases have no standard Java API. Where applicable, the aim of the specification is to map these onto the Java security model. Also there seem to be quite some synergies with the new Java Identity API (JSR 351) given it aims at unified security and compliance for Social Networking and Information services. 2.11 Are there any internationalization or localization issues?This specification uses the I18N support in Java 2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No, while this specification should build on top of well-established Java APIs like CDI, RESTful Web Services, JSON (JSR 353) or other yet to be filed JSRs there is no Java specification for Social Media as such, thus nothing can be directly replaced. 2.13 Please describe the anticipated schedule for the development of this specification.
Q1 2012: finalise expert group 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.The primary means of communication will be email (via mailing list) and conference calls, with meetings on IRC channels or Social Networks if deemed appropriate. Face-to-face meetings will be scheduled if needed. 2.15 Provide detailed answers to the transparency checklist, making sure to include URLs as appropriate:* The public can read the names of the people on the Expert Group. 2.16 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.Werner Keil and Antoine Sabot-Durand will deliver a Reference Implementation (RI) and Technology Compatibility Kit (TCK) compatible with Java (EE) 7 and where applicable Java ME 7. The license used will be the Apache Software License (ASL) 2.0, an open source license which is compatible with Java EE licensing. 2.17 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.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.Werner Keil and Antoine Sabot-Durand will deliver a Reference Implementation (RI) and Technology Compatibility Kit (TCK) compatible with Java EE 7. The license used will be the Apache Software License (ASL) 2.0, an open source license which is compatible with Java EE licensing. The Specification will use the standard license template. 2.19 Please describe the communications channel you have established for the public to observe Expert Group deliberations, provide feedback, and view archives of all Expert Group communications.java.net project, http://java.net/projects/java-social/lists. 2.20 What is the URL of the Issue Tracker that the public can read, and how does the public log issues in the Issue Tracker?java.net project, http://java.net/jira/browse/JAVA_SOCIAL 2.21 Please provide the location of the publicly accessible document archive you have created for the Expert Group.java.net project, http://java.net/projects/java-social/lists/jsr357-experts/archive Also there's a GitHub communityhttp://github.com/java-social and Google Grouphttp://groups.google.com/group/java-social 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.Open Social (http://docs.opensocial.org/) Open Social Java (http://code.google.com/p/opensocial-java-client/) Apache DeltaSpike Proposal (http://wiki.apache.org/incubator/DeltaSpikeProposal) Seam Social (http://seamframework.org/Seam3/SocialModule) Twitter4J (http://twitter4j.org) DaliCore (http://dalicore.java.net) Apache Shindig (http://shindig.apache.org/) SocialSite (http://socialsite.java.net) fb4java (http://code.google.com/p/fb4java/) Yahoo!?s Social APIs (http://developer.yahoo.com/social/) Google+ Java API (http://code.google.com/p/javaplus/) 3.2 Explanation of how these items might be used as a starting point for the work.With most authors of above frameworks discussions are in progress, how they might get involved. Especially those Inital EG Members or supporting the JSR wish to contribute solutions, and given some make great use of Java standards, or are considered to be used by other JSRs and implementations (e.g. Glassfish), those look especially promising. |
|||||||||||||||||||||||||||||||||||||||||||||||||||
