Chaupal, a P2P Framework
Chaupal is an Hindi word. It means a common meeting place in a village owned by the whole community. This truly reflects the P2P philosophy.
0. Proposal
Chaupal is to provide implementations of a P2P framework in several programming languages. It is a continuation of the JXTA P2P project. We are looking forward at reviewing and improving the existing JXTA protocol.
Update:
As of January 25th, 2011, we are still waiting for an answer from Oracle regarding intellectual property. Some members of the community have decided to create a separate project called Chaupal on Google Code (see http://code.google.com/p/chaupal/). Its purpose is to develop and implement a new set of P2P protocols independently of the JXTA protocols. These aim at solving structural designs and conceptual flaws in the current JXTA protocols, including providing solutions to issues not covered by JXTA. It is not a re-implementation of the JXTA protocols, nor an attempt to remain compatible with these. This new Chaupal project is developed under the Apache License 2.0.
1. Background
The JXTA project was initiated by Sun Microsystems in 2001, but since the end of 2007, Sun has has progressively reduced its commitment to zero. Recently, Oracle has officially announced its complete withdrawal from the project.
Since 2009, the JXTA community has taken over and has released version JXTA/JXSE 2.6 in July 2010. A complete knowledge transfer has been performed with a former leader from Sun Microsystems. The community has enough material to perform a new 2.7 release.
We can be reached via our dev mailing list (see https://jxta-jxse.dev.java.net/servlets/ProjectMailingListList)
2. Rationale
The JXTA community needs to find a new supportive environment to develop this project. We have voted overwhelmingly for ASF. There is currently no P2P projects at ASF. We believe this technology has a future and that ASF is a proper environment to nurture its development.
3. Initial Goals
- Release version 2.7 from Java.net/Kenai before moving to ASF
- Comply with ASF requirements before releasing 2.8 (or 3.0) from ASF
- Review and update code examples
- Improve our OSGi interface
- Implement NAT traversal
- Explore and implement binary transfer protocol
- Review and improve the JXTA protocols (followed by implementation)
- Extending test coverage core code.
- Re-engineer core code for better scaling and usage of resources
4. Current Status
Around 20 different individuals have contributed to the 2.6 release with patches, testing, and documentation. The technology is used live by a couple of companies. As mentioned above, we have enough material to perform a new release.
The community has complained about the quality of Java.net for a long time. About a year ago, we decided to initiate a move to Kenai. We had to put this on hold since the future of Kenai became uncertain following the Sun acquisition by Oracle. If our project is accepted by ASF, we will freeze that migration completely.
4.1 Meritocracy
The JXTA project was governed by a board of directors, but they did not organize elections in 2010. Since its inception, the community has operated according to the spirit of Open Source. Patches, release scopes and suggestions are reviewed and discussed by the community. Votes are performed when necessary. We believe we are compatible with the Apache spirit.
4.2 Community
The community was originally centered around Sun Microsystems, but many outside contributors have participated to the development of the technology right from the start. The firsts books where written by third parties. Since 2009, all the contributions to the project come from external parties.
4.3 Core Developers
The core developers belong to different companies and organizations. Some have been active for several years. Some are contributing to other open source projects too. Some members of the community focus only on testing released versions. It is a mixed crowd.
4.4 Alignment
The initial intention of the JXTA project was to define a P2P framework independently of any programming language. There are currently two main implementations: Java and C. The JXME implementation has not received much attention from the community and is more or less abandonned.
We are aligned with keeping any future version of the JXTA protocols independant from any programming language. The purpose is to facilitate the communication between peers operating under different environments.
We welcome contributions from other P2P frameworks too.
5. Known Risks
5.1 Orphaned products
The JXTA C implementation has been used by Boeing for several years. The Java implementation has been used by small companies. Oracle announced that won't be using JXTA in GlashFish anymore.
The community is small, but has proven its dedication with release 2.6 and upcomming release 2.7. We believe moving under ASF will only strengthen our community.
5.2 Inexperience with Open Source
The risk is null, since the project has been operating under open source principles right from the start.
5.3 Homogenous Developers
The risk is small to null, since the set of contributors has never been as diverse as it is right now.
5.4 Reliance on Salaried Developers
Medium. The community is a made of a set of salaried and free contributors, from different entities (private) and companies (public).
5.5 Relationships with Other Apache Products
We are not in conflict with other Apache products. In fact, we have taken the decision to avoid re-inventing the wheel and use existing open source libraries wherever possible. We welcome discussions with other Apache projects.
5.6 A Excessive Fascination with the Apache Brand
We have already proven we could deliver without the brand. We are looking for a better environment than Java.net or Kenai.
6. Documentation
As part of the 2.6 release, a huge effort has been performed to transfer knowledge from Sun Microsystemm to the community. The corresponding programmer's guide contains a chapter called 'Under the hood' which describes most of the complex mechanics of the code (see http://jxse.kenai.com).
A lot of information is available via Google from our posts in the forum. Our mailing list are registered and the email contents are available too.
A book called 'Practical JXTA' has been published in 2008. The second edition came out in summer 2010.
7. Initial Source
Initial source can be obtained from copying the current our subversion repository. We could upload it in an Apache subversion repository and discontinue our contributions to our current repository on Java.net (REM: it has not been completely migrated to Kenai yet).
DawningStreams, Inc. is willing to give its codes examples to ASF under Apache License 2.0. They are not part of the JXTA repository.
8. Source and Intellectual Property Submission Plan
Oracle is not willing to transfer the 'JXTA' trademark. Hence, we have voted for a new name: Chaupal.
There are some potential issues with existing patents. We have sent an email to legal-discuss@apache.org to discuss these. We have been told that a software grant would resolve the issue.
Our Oracle representative said he is looking into moving existing code from Apache license 1.1 to 2.0.
Update:
As of December 8th, 2010, Oracle is still performing due diligence on its intellectual property. We are waiting for feedback from them.
9. External Dependencies
During release 2.6, we mavenized the project. We are currently releasing our artifacts from an open source repository offered by Sonatype. We aim at being available from the central repository, but could not achieve this because of an open source dependency that was not available from central repository itself yet.
10. Cryptography
Release 2.7 will see the implementation of an operation membership and cryptography system.
11. Required Resources
Subversion repository Issue Tracker (Jira) Website location Wiki Mailing lists Forum (new)
12. Initial Committers
Simon Temple (Amalto) John Boyle (OneDrum) Jérôme Verstrynge (DawningStreams) Nick a.k.a. buzzlightyear (independant)
13. Sponsors
We don't have a sponsor yet. On the Apache Incubator list, Jochen Wiedmann said "I'm not qualified as a mentor, but I'm in for #3, which should help to get a sufficient number".