incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cliff Schmidt" <cliffschm...@gmail.com>
Subject Re: [VOTE] Accept Glasgow into Incubator
Date Thu, 03 Aug 2006 19:13:02 GMT
Coach, 

If you don't view your question as related to the vote, would you mind reposting it to a separate
or an existing thread about Glasgow?

Maybe it's just my personal preference, but I like to keep vote threads to just votes and
critical questions that were missed in the prior discussion (which, I admit, often doesn't
happen). 

Thanks,
Cliff
  
  

-----Original Message-----
From: "Coach Wei" <coach@nexaweb.com>
Date: Thu, 3 Aug 2006 11:32:14 
To:<general@incubator.apache.org>
Subject: RE: [VOTE] Accept Glasgow into Incubator

+1 (non binding) from me.

A question unrelated to voting: What is the possible (estimated) minimum
implementation footprint (in term of kilobytes or megabytes) to support
AMQP network wire-level protocol? I am asking this thinking of the
possibility of using AMQP protocol in mobile applications such as J2ME. 

---Coach Wei

> -----Original Message-----
> From: Cliff Schmidt [mailto:cliffschmidt@gmail.com]
> Sent: Thursday, August 03, 2006 12:52 PM
> To: general@incubator.apache.org
> Subject: [VOTE] Accept Glasgow into Incubator
> 
> I believe all open questions about the Glasgow proposal (originally
> submitted as "Blaze") have now been addressed enough to call a vote
> for accepting the project for incubation.
> 
> Therefore, as the champion of this project, I am calling a vote.  As
> usual, the binding votes will be those case by Incubator PMC members
> (since the project is requesting sponsorship from the Incubator PMC);
> however all participants on this list are encouraged to vote if they
> have a strong feeling one way or another.
> 
> The traditional 72-hour voting period would end during a weekend for
> most timezones; so I propose extending that by an additional day, with
> the vote closing on Monday, August 7, 2006 17:00 UTC / 10:00 PDT (see
>
http://www.timeanddate.com/worldclock/fixedtime.html?month=8&day=7&year=
20
> 06&hour=17&min=0&sec=0&p1=0)
> 
> Please vote on the Glasgow proposal, as described below, which can
> also be found at:
> http://wiki.apache.org/incubator/GlasgowProposal?action=recall&rev=1.
> 
> Note the old wiki page (with the full history of changes since the
> original proposal) can be found here:
> http://wiki.apache.org/incubator/Blaze
> 
> Cliff
> 
> ----
> = Glasgow Proposal (renamed from Blaze) =
> 
> == RATIONALE ==
> Glasgow provides multiple language implementations of the Advanced
> Messaged Queuing Protocol (AMQP) specification and related
> technologies including PGM, transaction management, queuing,
> distribution, security, management and heterogeneous multi-platform
> support for messaging (links to these specifications are in the
> "Initial Source" section of this proposal.)
> Glasgow's overall goal is to create an open and interoperable
> implementation for messaging which implements the emerging AMQP
> specification, in keeping with the philosophy of the Foundation. This
> implementation will provide a messaging solution that will be language
> and platform agnostic by using a well defined wire specification.
> Providing both libraries for the framing and protocol in addition to
> brokers in both Java and C/C++ allows for integration with Apache and
> non-Apache projects in a manner that facilitates heterogeneous
> deployment with full interoperability for SOA & distributed systems.
> The seed code for the project will consist of in-progress C/C++ and
> Java implementations of the AMQP specification that we intend to
> continue development on in conjunction with other Apache communities.
> More information on the scope of the seed code can be found in
> subsequent sections of this proposal.
> 
> == CRITERIA ==
> === Meritocracy: ===
> The Glasgow committers recognize the desirability and necessity of
> running this project as a full meritocracy; indeed, the scope of the
> project's technical aspects are so varied that we find it hard to
> envision success any other way. One of the most important lessons that
> can be derived from the historic evolution of middleware is that
> specifications architected in isolation from real usable code that has
> been developed to solve tangible, real world problems or amongst a
> narrowly restricted list of contributors often do not see widespread
> adoption. Our goal in crafting this implementation and providing our
> learning to the specification team is to develop the best possible
> language agnostic advanced message queuing platform.  We understand
> that in order to do so, we will need to engage all interested  members
> of the community and operate to the standard of meritocracy that
> characterizes successful Apache projects.
> 
> === Community: ===
> The project's primary objective is to build a vibrant community of
> users and active contributors.  Although Glasgow is not based on an
> existing open source community, many of the initial contributors have
> experience participating in and building other open source
> communities.  Several of the contributors have previously participated
> in Apache communities. We understand that Apache's community
> governance protocols are a unique contributor to the success of
> Apache's project communities and we are eager to learn from our
> Incubator mentors so that we can evolve Glasgow into a healthy and
> sustainable community.
> === Core Developers: ===
> Most of the initial committers are members of Red Hat, IONA, and JP
> Morgan Chase's (JPMC) development teams. Additional developers will be
> added through the Apache community process.
> === Alignment: ===
> An initial implementation has been written in Java and C++, which will
> be refactored into this project to form the initial code base.  We
> have had a few exploratory conversations about integration with
> individuals of other communties such as Apache Geronimo, Tuscany,
> ActiveMQ, Fedora and ObjectWeb's Celtix and hope to work towards
> future collaboration with these communities. Our current
> implementation makes extensive use of projects from the Apache Jakata
> Commons, Mina and other Apache infrastructure projects. A
> compatibility binding for JMS also exists. It is however important to
> note that this is NOT a JMS project and aims to solve a different
> problem space, providing language and platform independent and
> interoperable messaging, driven by a protocol specification which may
> ultimately be commoditized in hardware.
> 
> The scope of the project is broader than just Java and C++ as the
> project will also look at providing bindings in other languages such
> as PHP and Python.Additionally, bindings have already been created for
> test automation.
> As Glasgow's broad goal is to create a standardized, widely available,
> and  interoperable messaging solution based on the AMQP protocol,
> there are numerous potential collaboration opportunities with many
> other Apache projects including:
>  * Transport support for Geronimo
>   * Interoperability integration with ActiveMQ(JMS)
>  * Integration with Axis for SOAP messaging over an asynchronous
transport
>   * Language/platform neutral interoperable messaging for projects
> like Synapse and ServiceMix
> 
> == AVOIDING THE WARNING SIGNS ==
> === Orphaned products: ===
> The initial code submission is based on active code developed and we
> believe that through its continued evolution in an open community will
> lead to a stronger, more widely accepted foundation for development of
> middleware and be valuable to many other Apache and community
> projects.
> === Inexperience with open source: ===
> Many of the initial committers have experience working on open source
> projects and several are committers on other Apache projects. Each of
> the companies involved in the initial submission has prior success
> building or contributing to open source projects. Moreover, some of
> the initial companies involved focus exclusively on developing open
> source software.  This depth and diversity of experience fosters a
> deep understanding of managing and running open source projects.
> === Homogenous developers: ===
> The current list of committers includes developers from several
> different companies who are geographically distributed across the U.S.
> and Europe. They are experienced with working in a distributed
> environment and with resolving technical differences outside the scope
> of a common employer.
> === Reliance on salaried developers: ===
> Most of the initial developers are paid by their employers to
> contribute to this project; however, this submission includes
> employers with track records for ongoing investment in open source
> communities (including Apache, Eclipse, ObjectWeb and Fedora).
> === No ties to other Apache products: ===
> As described in the Alignment section,this framework already leverages
> existing Apache projects. by making use of  other Apache projects for
> infrastructure building blocks. The initial codebase will be licensed
> under the Apache License 2.0.
> === A fascination with the Apache brand: ===
> The committers are intent on developing a strong open source community
> around what we hope will be a best-in-class, enterprise-grade high
> performance messaging framework.  We believe that the Apache Software
> Foundation's emphasis on community open development makes it the most
> suitable choice for such a project. We understand that the Apache
> brand has become synonymous with the values of quality, meritocracy,
> and community, and we endeavor to make our project worthy of such an
> affiliation. We also commit to working proactively with the Public
> Relations Committee to ensure that any marketing or promotional
> activities we pursue are in compliance with the ASF's policies.
> 
> == SCOPE OF SUBPROJECTS ==
> The initial contributors envision an active community of related
> projects sharing a common of commodity and interoperable middleware
> but targeting specific technical areas:
> Glasgow will be seeded with several projects based on donated material
> (see the next section):
>  * a Java implementation of the wire level framing
>  * a C++ implementation of the wire level framing
>  * a Java implementation of a broker
>   * a Java implementation of a JMS interface
>   * a C++ implementation of a portability layer, which will be
> refactored to be pluggable
>   * an implementation of the broker with will be refactrored into C++,
> for existing work and possible use of GCJ
> To assist in community building, the committers have identified
> several key technology areas that will allow new contributors points
> of entry to actively engage in the project. These include:
>   * integration with other Apache projects (Tuscany, ActiveMQ,
> ServiceMix, Apache Axis)
>   * integration with security and both local and distributed
transactions
> (XA)
>   * support heterogeneous API bindings in C, C++, Java, PHP, Python
and
> BPEL
>   * support for cross memory or RDMA transports
>   * support for in process IPC clients or IPC transport bindings
>   * support for broadcast and relay from PGM <--> AMQP
>   * integration with payload marshilling toolkits
>   * Declarative policy based API's
> These initial projects are intended merely as starting points and
> should not be taken as bounding the scope of the Glasgow project as a
> whole. Some other potential projects may include:
>   * Integration with rich middleware frameworks (such as Celtix or
> ServiceMix).
>  * Support and integration of Security.
>  * Management tools.
>  * Support for additional class frames such as tunneling
> 
> == INITIAL SOURCE ==
> A group of companies are developing a set of specifications relating
> to the creation of commodity enterprise class messaging, collectively
> called Advanced Message Queuing Protocol (AMQP). In progress versions
> are available at:
>  * http://www.envoytech.org/spec/amqp/
>  * http://www.iona.com/opensource/amqp/
>  * http://www.redhat.com/solutions/specifications/amqp/
>  * http://www.twiststandards.org/tiki-index.php?page=AMQ
>  * http://www.faqs.org/rfcs/rfc3208.html
> 
> 
> The initial contributors have been developing Java and C++ code bases
> (licensed under the Apache License 2.0) which implement aspects of
> these specifications, and intend to donate it to Apache. The current
> working svn is available at:
> https://etp.108.redhat.com/source/browse/etp/trunk/blaze
> 
> Although the Glasgow project expects to bootstrap using these
> materials and in the case of specifications, to provide feedback that
> will be incorporated into their ongoing development, we expect and
> encourage the open source community to take the project in new
> directions not envisioned by them to create a world class
> implementation of the AMQP specification and related technologies.
> 
> == Interactions with the specifications ==
> The specification is being developed by group of companies, under a
> contract that requires the resulting work to be published to a
> standards body. This model has been chosen to assure that anyone that
> contributes to the specification grants a copyright and patient
> license to all contributions made to the specification on every
> publication (draft or final). This ensures that the specification will
> always be open and implementable by anyone without royalties or
> commercial limitations. We feel that this is a very strong model for
> keeping this work entirely open and will fit well with the Apache
> project enabling innovations to pass in both directions across the
> extended community.
> 
> Dealing with feedback from the Glasgow project to specifications
> It is key that the best implementation and specifications be created
> based on technical merit and practicalities for adoption by both the
> parties developing the specification and the committers within the
> Apache community. Given this, one of the important aspects is how
> issues discovered during the development of this implementation are
> incorporated back into the specifications.  The following feedback
> loop exists to ensure that any specification input incuding the
> Glasgow community can have their feedback incorporated into the
> specifications.
> === MECHANISMS FOR FEEDBACK ===
> a.) In the same way anyone can issue a JIRA on any Apache project
> having signed the Apache CLA, anyone can issue a "JIRA" to the
> specification working group through the RLA (Reviewer License
> Agreement). This agreement provides a license to that IP so that the
> specification team can incorporate it and the specifaction as they
> like and the specifications can remain entirely open and royalty free.
> b.) In the same spirit of Apache, if an individual has shown
> understanding of the project and substantive contribution to the
> specification, a vote based on technical merit and understanding of
> the goals of the work can be initiated to have that parties Employer
> join the specification working group. On such acceptance the employer
> is required to sign an agreement to make sure that employer also
> grants the ongoing and consistent licenses to the work as posted in
> specifications.
> 
> The Reviewer License Agreement (RLA) can be viewed from the AMQP
> specification page of any of the members as listed above.
> 
> == ASF resources to be created ==
> mailing list(s)
>   * glasgow-dev
>   * glasgow-commits
> Subversion repository
>   * https://svn.apache.org/repos/asf/incubator/glasgow
> Jira
>  * Glasgow (GLASGOW)
> 
> === INITIAL COMMITTERS ===
>   * Rajith Attapattu (Red Hat)
>   * Mark Atwell (JPMC)
>  * Bela Ban (Red Hat)
>   * Bhupendra Bardwaj (JPMC)
>  * Alan Conway (Red Hat)
>   * Tejeswar Das (IONA)
>   * Ovidiu Feodorov  (Red Hat)
>  * Tim Fox (Red Hat)
>   * Paul Fremantle (WSO2)
>   * Eoghan Glynn (IONA)
>   * Robert Greig (JPMC)
>   * Chamikara Jayalath (WSO2)
>  * Sam Joyce (IONA)
>   * John O'Hara (JPMC)
>  * Frank Lynch (IONA)
>   * Marnie McCormack (JPMC)
>   * Martin Ritchie (JPMC)
>   * Rafael Schloming (Red Hat)
>   * Archit Shah (Red Hat)
>   * Stephen Shaw (JPMC)
>  * Gordon Sim (Red Hat)
>   * James Strachan (LogicBlaze)
>   * Manik Surtani (Red Hat)
>  * Paul Taylor (IONA)
>   * Carl Trieloff (Red Hat)
>   * Kim van der Riet (Red Hat)
>   * Steve Vinoski (IONA)
>   * Sergey Yedrikov (IONA)
> 
> === APACHE SPONSOR ===
> The Glasgow team will make the submission to the incubator as the
> sponsor for incubation.
> 
> Champion
>  * Cliff Schmidt (consultant to Red Hat)
> Mentors:
>   * James Strachan
>  * Cliff Schmidt (consultant to Red Hat)
>   * Paul Fremantle
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Mime
View raw message