[VOTE] accept Etch into the Incubator

[James Dixson <ja...@cisco.com>]

Please vote on accepting Etch into the Incubator.

The Etch proposal is at:

   http://wiki.apache.org/incubator/EtchProposal


-- 
James 



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

Re: [VOTE] accept Etch into the Incubator

[Roland Weber <os...@dubioso.net>]

+1 (binding)

cheers,
   Roland

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

Re: [VOTE] accept Etch into the Incubator

["Edward J. Yoon" <ed...@apache.org>]

+1 (non-binding)

-Edward

On Wed, Aug 27, 2008 at 4:02 PM, Paul Fremantle <pz...@gmail.com> wrote:
> +1
>
> Paul
>
>
> On Wed, Aug 27, 2008 at 7:42 AM, ant elder <an...@gmail.com> wrote:
>> +1
>>
>>   ...ant
>>
>> On Mon, Aug 25, 2008 at 7:09 PM, Yonik Seeley <yo...@apache.org> wrote:
>>
>>> Since wiki pages can change, the full text of the proposal needs to be
>>> in the vote thread.
>>> Here is the text of the proposal:
>>>
>>> == Abstract ==
>>>
>>> Etch is a cross-platform, language- and transport-independent
>>> framework for building and consuming network services.
>>>
>>> == Proposal ==
>>>
>>> Etch is a cross-platform, language- and transport-independent
>>> framework for building and consuming network services. The Etch
>>> toolset includes a network service description language, a compiler,
>>> and binding libraries for a variety of programming languages. Etch is
>>> also transport-independent, allowing for a variety of different
>>> transports to used based on need and circumstance. The goal of Etch is
>>> to make it simple to define small, focused services that can be easily
>>> accessed, combined, and deployed in a similar manner. Ultimately with
>>> Etch, service development and consumption becomes no more difficult
>>> than library development and consumption.
>>>
>>> == Background ==
>>>
>>> Etch was started because we wanted to have a way to write a concise,
>>> formal description of the message exchange between a client and a
>>> server, with that message exchange supporting a hefty set of
>>> requirements. The messaging technology should support one-way and
>>> two-way, real-time communication. It should have high performance and
>>> scalability. I should support clients and servers written in different
>>> languages. It should also support clients/servers running in a wide
>>> range of contexts (such as thin web client, embedded device, PC
>>> application, or server). It must support anyone adding new language
>>> bindings and new transports. It should also be fast and small, while
>>> still being flexible enough to satisfy requirements. Finally, it must
>>> be easy to use for developers both implementing and/or consuming the
>>> service.
>>>
>>> == Rationale ==
>>>
>>> Existing systems were either too slow, hard to use, bloated and/or
>>> proprietary. In any case, none fit our matrix of requirements
>>> perfectly.
>>>
>>> Developers of applications that must leverage the capabilities of
>>> network-hosted services have a daunting challenge. They must cobble
>>> together a heterogeneous collection of services that expose different
>>> APIs with different communications technologies just to integrate with
>>> the services, essentially spending a great deal of energy and effort
>>> on just the basics of inter-service communication rather than core
>>> business logic.
>>>
>>> So the desired state then is when developing applications that
>>> leverage the capabilities of dispersed and heterogeneous network
>>> services, APIs must be simple, cohesive, and coherent across network
>>> services. APIs should be easy to consume by developers regardless of
>>> the implementation technology of the service used or the domain a
>>> service is being built within- from client-side web applications to
>>> complex real-time server systems. Put simply, developers ideally
>>> should feel that they are developing to a platform.
>>>
>>> API development is a much better understood and simpler subject if you
>>> are building those APIs to be run _locally_ on a single machine or
>>> service. Microsoft and Linux centric API developers have the luxury of
>>> the massive assumption that a standard OS is available with a certain
>>> set of features, and the API libraries do not have to take into
>>> account the complexities of APIs that cross machine or OS boundaries.
>>>
>>> Developers of network-centered services, rather than OS-centered
>>> services, do not have this luxury; we have a significant set of issues
>>> facing us today because of the fundamental fact that "the network" is
>>> not a single machine, or a homogeneous set of machines, but a
>>> heterogeneous and widely distributed set of services.
>>>
>>> The conventional method for developers of network services today is to
>>> use either a technology specific to the language of preference, RMI
>>> for Java, .NET Remoting for .NET for C#, etc., or if trying to be
>>> "language neutral" picking a CORBA ORB or a Web Service technology
>>> like SOAP or REST. These choices are fine until the requirements of
>>> the application cannot accept the limitations of the remoting
>>> technology. If the application needs to work on non-Microsoft
>>> platforms, .NET Remoting is out (unless, of course, you can use the
>>> Mono implementation of .NET, but that brings with it other
>>> challenges). If the need is to support access from languages other
>>> than Java, then RMI is out. If the need includes support for
>>> real-time, asynchronous communication, or symmetric two-way
>>> communications, the Web services technologies must also be rejected.
>>>
>>> For other classes of applications, there are simply no "standard"
>>> choices left. The developer is forced to drop down to a network
>>> protocol level and invent a new messaging system for their needs.
>>> Building a protocol by hand is hard; building a messaging system is
>>> also hard. This dramatically increases the barrier to entry for new,
>>> useful applications that leverage network-services.
>>>
>>> An orthogonal problem exists when supporting more than one transport
>>> technology is required of the application, e.g. HTTP/SOAP and
>>> HTTP/REST or HTTP/SOAP and a proprietary service protocol. This is
>>> also burdensome to the developer because now two or more distinct
>>> technologies must be used to expose the same interface. This typically
>>> means the development and maintenance of parallel implementations of
>>> the service using the technologies native to the transport mechanism.
>>> Often the result here is that one interface is the complete interface,
>>> while others suffer from various levels of partial or out-of-sync
>>> implementation.
>>>
>>> What if this was the reality instead: every interface to a network
>>> service could be had via a single, common API technology that 'just
>>> works' in every major language (C#, Java, Python, Ruby, C or even
>>> Javascript in a browser). What if this technology could produce the
>>> native stub code needed to do the networking and message passing (much
>>> like Web Services). Then the developer could concentrate on the
>>> business logic of the application or service rather than the
>>> idiosyncrasies of the network plumbing.
>>>
>>> As a language and transport independent network API generator, Etch
>>> can provide programmers with a consistent API model to program against
>>> while giving them the ability to redeploy into a variety of languages
>>> or transports at runtime (per developer/customer choice). So, one may
>>> use the same API implementation to send messages using an XML coding
>>> on a stream protocol in Java, or binary coding wrapped in reliable UDP
>>> in C#, or a shared memory queue on a router backplane in C, or even
>>> Python over SOAP. One could, in fact, support all at the same time,
>>> and any others that you care to implement or find, as long as you
>>> support the required semantics of the API.
>>>
>>> It all comes down to this: developers should not have to care about
>>> the implementation language or platform of the service nor what the
>>> transport is to get there, as long as basic semantics are honored, and
>>> these should be no more or less than the semantics of your programming
>>> language of choice. Further, a user requirement about specific
>>> protocols should not require rewriting of application logic to make it
>>> fit into some arbitrary framework scheme or container.
>>>
>>> == Current Status ==
>>>
>>> === Meritocracy ===
>>>
>>> Etch was conceived by Scott Comer and Louis Marascio. As Scott
>>> finished the development of the core compiler and first transport
>>> implementation, others have made various contributions to the project:
>>> James Dixson and Shawn Dempsey have worked on the build environment;
>>> Manoj Ganesan has worked on a Ruby binding; James Dixson on the Python
>>> binding; and James deCocq on the C binding; Manoj Ganesan and Gaurav
>>> Sandhir did primary work on C# and maintenance work all around. J.D.
>>> Liau has been instrumental in ideas and maintenance. Hung Nguyen has
>>> created the Windows installer using NSIS and Seth Call is working on a
>>> JavaScript binding with JSON transport for thin clients.
>>>
>>> === Community ===
>>>
>>> Etch solves problems lots of projects have. Any project that has a
>>> need to define multiple services in a consistent way, or expose
>>> services on the network to a variety of languages or platforms can
>>> benefit from Etch as technology.
>>>
>>> === Core Developers ===
>>>
>>>
>>> The core developers are all listed in the initial committers list
>>> later in this proposal.
>>>
>>> === Alignment ===
>>>
>>> The compiler code is in Java, but the technology is language- and
>>> protocol-agnostic and suitable for many different projects, including
>>> non-Java. The compiler makes use of Apache Ant for orchestrating the
>>> build, and Apache Velocity for code generation.
>>>
>>> == Known Risks ==
>>>
>>> === Orphaned Products ===
>>>
>>> We are all quite committed to Etch and the development of an Etch
>>> community. Etch is a core component of shipping Cisco products and
>>> will only grow over time.
>>>
>>> Our employer is also committed to the success of the technology,
>>> allowing us to continue to invest our time in support of Etch
>>> development as well as committing to Etch technology as a key
>>> component in multiple products.
>>>
>>> Etch being orphaned is unlikely.
>>>
>>> === Inexperience with Open Source ===
>>>
>>> The group of initial committers has had various levels of interaction
>>> with open-source communities. Most of us came into Cisco through the
>>> acquisition of Metreos in 2006. While at Metreos, Louis Marascio and
>>> several of us were active contributor's to the OpenH323 project. We
>>> worked through several bugs, submitted patches and even sponsored
>>> development. We have also made contributions to other projects (some
>>> accepted, some not) on a much smaller scale over the years, QDox,
>>> Maruku, Capistrano, OpenGatekeeper, and Mono.
>>>
>>> === Homogeneous Developers ===
>>>
>>> Etch has been completely developed by Cisco employees, therefore all
>>> of the initial committers to the project are affiliated with Cisco.
>>>
>>> Etch has just recently been made publicly available. First in binary
>>> form in May 2008 as part of a Cisco product and in open source form in
>>> July 2008.
>>>
>>> === Reliance on Salaried Developers ===
>>>
>>> It is expected that Etch development will be done both on salaried
>>> time and volunteer time. Cisco is highly interested in the success and
>>> development of an Etch community. At this time, Etch is a core
>>> component of shipping Cisco products and is likely to grow over time.
>>> Cisco in interested in investing time to support Etch development and
>>> use it as a key component in multiple products. It is also expected
>>> that non-Cisco developers will become interested in Etch.
>>>
>>> === Relationships with Other Apache Products ===
>>>
>>> Etch currently depends upon these other Apache projects: Velocity,
>>> Maven and Ant.
>>>
>>> We expect that as Etch becomes available, it will be seen as a very
>>> compelling technology and others will begin to depend upon it.
>>>
>>> === A Excessive Fascination with the Apache Brand ===
>>>
>>> We believe Etch offers much to the Apache brand. We could easily, with
>>> the backing of Cisco, take a more independent route and support Etch
>>> directly without the Apache foundation. But after much consideration,
>>> we truly believe that would be the wrong approach for this technology.
>>>
>>> As a technology, we believe Etch is very much a kindred spirit of the
>>> other software infrastructure technologies currently part of the
>>> Apache community: Ant, Velocity, Derby, and others. The technological
>>> niche of Etch--platform and language agnostic service definition and
>>> binding-is a technology that can be appreciated across a broad range
>>> software domains.
>>>
>>> It is our view that Apache is simply the most appropriate community
>>> for the kind of technology Etch represents.
>>>
>>> == Documentation ==
>>>
>>> Public documents are available. All documentation can be found here
>>> http://developer.cisco.com/web/cuae/etch .
>>>
>>> == Initial Source ==
>>>
>>> Etch has been in development at Cisco since Jan-2007. The system was
>>> designed from the beginning to be open-sourced.  We consider Etch to
>>> be at release 1.0 and ready for production use.
>>>
>>> We continue to develop on Etch aggressively and a continually adding
>>> tests and documentation to accompany the code, in particular around
>>> Etch's unique pluggable architecture.
>>>
>>> The compiler and language bindings for Java and C# are working and
>>> functional. Etch will be included in shipping Cisco products in
>>> Sept-2008 as a core technology component.
>>>
>>> The language bindings for JavaScript, Python and C are in development.
>>> The Etch development home page is currently hosted a Cisco's developer
>>> portal: http://developer.cisco.com/web/cuae/etch . Full source and
>>> binary distributions are available there including access to our
>>> public subversion repository.
>>>
>>> == Source and Intellectual Property Submission Plan ==
>>>
>>> Apache would receive all source and documentation under the Apache
>>> Corporate Contributor agreement. Cisco is the only license holder.
>>>
>>> == External Dependencies ==
>>>
>>> Java, JavaCC and Velocity are core dependencies of the compiler. The
>>> Java language binding depends only on Java.
>>>
>>> Ant and Maven are used by the build system.
>>>
>>> For the other language bindings we have the following compile/link
>>> dependencies:
>>>
>>> C# - Microsoft .NET v2.0 (Mono compatibility coming soon)
>>>
>>> == Cryptography ==
>>>
>>> Etch uses the native capabilities of Java and C# to support TLS as an
>>> option for the default Etch binary transport protocol.
>>>
>>> == Required Resources ==
>>>
>>> === Mailing Lists ===
>>>
>>>  * etch-private
>>>  * etch-dev
>>>  * etch-commits
>>>  * etch-user
>>>
>>> === Subversion Directory ===
>>>
>>>  https://svn.apache.org/repos/asf/incubator/etch
>>>
>>> === Issue Tracking ===
>>>
>>>  JIRA : Etch (ETCH)
>>>
>>> === Other Resources ===
>>>
>>>  None
>>>
>>> == Initial Committers ==
>>>
>>>
>>> Gaurav Sandhir      gsandhir at cisco dot com
>>>
>>> J.D. Liau           jliau at cisco dot com
>>>
>>> James Dixson        jadixson at cisco dot com
>>>
>>> James deCocq      jadecocq at cisco dot com
>>>
>>> Rene Barazza        rebarraz at cisco dot com
>>>
>>> Scott Comer         sccomer at cisco dot com
>>>
>>> Seth Call           secall at cisco dot com
>>>
>>> Youngjin Park     youngjpa at cisco dot com
>>>
>>> === Affiliations ===
>>>
>>> All the initial committers are Cisco employees.
>>>
>>> == Sponsors ==
>>>
>>> === Champion ===
>>>
>>> Niclas Hedhman (has offered to be Champion)
>>>
>>> === Nominated Mentors ===
>>>
>>> Niclas Hedhman
>>>
>>> Doug Cutting
>>>
>>> Yonik Seeley
>>>
>>> === Sponsoring Entity ===
>>>
>>> Incubator
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>
>
>
>
> --
> Paul Fremantle
> Co-Founder and CTO, WSO2
> Apache Synapse PMC Chair
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>



-- 
Best regards, Edward J. Yoon
edwardyoon@apache.org
http://blog.udanax.org

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

Re: [VOTE] accept Etch into the Incubator

[Paul Fremantle <pz...@gmail.com>]

+1

Paul


On Wed, Aug 27, 2008 at 7:42 AM, ant elder <an...@gmail.com> wrote:
> +1
>
>   ...ant
>
> On Mon, Aug 25, 2008 at 7:09 PM, Yonik Seeley <yo...@apache.org> wrote:
>
>> Since wiki pages can change, the full text of the proposal needs to be
>> in the vote thread.
>> Here is the text of the proposal:
>>
>> == Abstract ==
>>
>> Etch is a cross-platform, language- and transport-independent
>> framework for building and consuming network services.
>>
>> == Proposal ==
>>
>> Etch is a cross-platform, language- and transport-independent
>> framework for building and consuming network services. The Etch
>> toolset includes a network service description language, a compiler,
>> and binding libraries for a variety of programming languages. Etch is
>> also transport-independent, allowing for a variety of different
>> transports to used based on need and circumstance. The goal of Etch is
>> to make it simple to define small, focused services that can be easily
>> accessed, combined, and deployed in a similar manner. Ultimately with
>> Etch, service development and consumption becomes no more difficult
>> than library development and consumption.
>>
>> == Background ==
>>
>> Etch was started because we wanted to have a way to write a concise,
>> formal description of the message exchange between a client and a
>> server, with that message exchange supporting a hefty set of
>> requirements. The messaging technology should support one-way and
>> two-way, real-time communication. It should have high performance and
>> scalability. I should support clients and servers written in different
>> languages. It should also support clients/servers running in a wide
>> range of contexts (such as thin web client, embedded device, PC
>> application, or server). It must support anyone adding new language
>> bindings and new transports. It should also be fast and small, while
>> still being flexible enough to satisfy requirements. Finally, it must
>> be easy to use for developers both implementing and/or consuming the
>> service.
>>
>> == Rationale ==
>>
>> Existing systems were either too slow, hard to use, bloated and/or
>> proprietary. In any case, none fit our matrix of requirements
>> perfectly.
>>
>> Developers of applications that must leverage the capabilities of
>> network-hosted services have a daunting challenge. They must cobble
>> together a heterogeneous collection of services that expose different
>> APIs with different communications technologies just to integrate with
>> the services, essentially spending a great deal of energy and effort
>> on just the basics of inter-service communication rather than core
>> business logic.
>>
>> So the desired state then is when developing applications that
>> leverage the capabilities of dispersed and heterogeneous network
>> services, APIs must be simple, cohesive, and coherent across network
>> services. APIs should be easy to consume by developers regardless of
>> the implementation technology of the service used or the domain a
>> service is being built within- from client-side web applications to
>> complex real-time server systems. Put simply, developers ideally
>> should feel that they are developing to a platform.
>>
>> API development is a much better understood and simpler subject if you
>> are building those APIs to be run _locally_ on a single machine or
>> service. Microsoft and Linux centric API developers have the luxury of
>> the massive assumption that a standard OS is available with a certain
>> set of features, and the API libraries do not have to take into
>> account the complexities of APIs that cross machine or OS boundaries.
>>
>> Developers of network-centered services, rather than OS-centered
>> services, do not have this luxury; we have a significant set of issues
>> facing us today because of the fundamental fact that "the network" is
>> not a single machine, or a homogeneous set of machines, but a
>> heterogeneous and widely distributed set of services.
>>
>> The conventional method for developers of network services today is to
>> use either a technology specific to the language of preference, RMI
>> for Java, .NET Remoting for .NET for C#, etc., or if trying to be
>> "language neutral" picking a CORBA ORB or a Web Service technology
>> like SOAP or REST. These choices are fine until the requirements of
>> the application cannot accept the limitations of the remoting
>> technology. If the application needs to work on non-Microsoft
>> platforms, .NET Remoting is out (unless, of course, you can use the
>> Mono implementation of .NET, but that brings with it other
>> challenges). If the need is to support access from languages other
>> than Java, then RMI is out. If the need includes support for
>> real-time, asynchronous communication, or symmetric two-way
>> communications, the Web services technologies must also be rejected.
>>
>> For other classes of applications, there are simply no "standard"
>> choices left. The developer is forced to drop down to a network
>> protocol level and invent a new messaging system for their needs.
>> Building a protocol by hand is hard; building a messaging system is
>> also hard. This dramatically increases the barrier to entry for new,
>> useful applications that leverage network-services.
>>
>> An orthogonal problem exists when supporting more than one transport
>> technology is required of the application, e.g. HTTP/SOAP and
>> HTTP/REST or HTTP/SOAP and a proprietary service protocol. This is
>> also burdensome to the developer because now two or more distinct
>> technologies must be used to expose the same interface. This typically
>> means the development and maintenance of parallel implementations of
>> the service using the technologies native to the transport mechanism.
>> Often the result here is that one interface is the complete interface,
>> while others suffer from various levels of partial or out-of-sync
>> implementation.
>>
>> What if this was the reality instead: every interface to a network
>> service could be had via a single, common API technology that 'just
>> works' in every major language (C#, Java, Python, Ruby, C or even
>> Javascript in a browser). What if this technology could produce the
>> native stub code needed to do the networking and message passing (much
>> like Web Services). Then the developer could concentrate on the
>> business logic of the application or service rather than the
>> idiosyncrasies of the network plumbing.
>>
>> As a language and transport independent network API generator, Etch
>> can provide programmers with a consistent API model to program against
>> while giving them the ability to redeploy into a variety of languages
>> or transports at runtime (per developer/customer choice). So, one may
>> use the same API implementation to send messages using an XML coding
>> on a stream protocol in Java, or binary coding wrapped in reliable UDP
>> in C#, or a shared memory queue on a router backplane in C, or even
>> Python over SOAP. One could, in fact, support all at the same time,
>> and any others that you care to implement or find, as long as you
>> support the required semantics of the API.
>>
>> It all comes down to this: developers should not have to care about
>> the implementation language or platform of the service nor what the
>> transport is to get there, as long as basic semantics are honored, and
>> these should be no more or less than the semantics of your programming
>> language of choice. Further, a user requirement about specific
>> protocols should not require rewriting of application logic to make it
>> fit into some arbitrary framework scheme or container.
>>
>> == Current Status ==
>>
>> === Meritocracy ===
>>
>> Etch was conceived by Scott Comer and Louis Marascio. As Scott
>> finished the development of the core compiler and first transport
>> implementation, others have made various contributions to the project:
>> James Dixson and Shawn Dempsey have worked on the build environment;
>> Manoj Ganesan has worked on a Ruby binding; James Dixson on the Python
>> binding; and James deCocq on the C binding; Manoj Ganesan and Gaurav
>> Sandhir did primary work on C# and maintenance work all around. J.D.
>> Liau has been instrumental in ideas and maintenance. Hung Nguyen has
>> created the Windows installer using NSIS and Seth Call is working on a
>> JavaScript binding with JSON transport for thin clients.
>>
>> === Community ===
>>
>> Etch solves problems lots of projects have. Any project that has a
>> need to define multiple services in a consistent way, or expose
>> services on the network to a variety of languages or platforms can
>> benefit from Etch as technology.
>>
>> === Core Developers ===
>>
>>
>> The core developers are all listed in the initial committers list
>> later in this proposal.
>>
>> === Alignment ===
>>
>> The compiler code is in Java, but the technology is language- and
>> protocol-agnostic and suitable for many different projects, including
>> non-Java. The compiler makes use of Apache Ant for orchestrating the
>> build, and Apache Velocity for code generation.
>>
>> == Known Risks ==
>>
>> === Orphaned Products ===
>>
>> We are all quite committed to Etch and the development of an Etch
>> community. Etch is a core component of shipping Cisco products and
>> will only grow over time.
>>
>> Our employer is also committed to the success of the technology,
>> allowing us to continue to invest our time in support of Etch
>> development as well as committing to Etch technology as a key
>> component in multiple products.
>>
>> Etch being orphaned is unlikely.
>>
>> === Inexperience with Open Source ===
>>
>> The group of initial committers has had various levels of interaction
>> with open-source communities. Most of us came into Cisco through the
>> acquisition of Metreos in 2006. While at Metreos, Louis Marascio and
>> several of us were active contributor's to the OpenH323 project. We
>> worked through several bugs, submitted patches and even sponsored
>> development. We have also made contributions to other projects (some
>> accepted, some not) on a much smaller scale over the years, QDox,
>> Maruku, Capistrano, OpenGatekeeper, and Mono.
>>
>> === Homogeneous Developers ===
>>
>> Etch has been completely developed by Cisco employees, therefore all
>> of the initial committers to the project are affiliated with Cisco.
>>
>> Etch has just recently been made publicly available. First in binary
>> form in May 2008 as part of a Cisco product and in open source form in
>> July 2008.
>>
>> === Reliance on Salaried Developers ===
>>
>> It is expected that Etch development will be done both on salaried
>> time and volunteer time. Cisco is highly interested in the success and
>> development of an Etch community. At this time, Etch is a core
>> component of shipping Cisco products and is likely to grow over time.
>> Cisco in interested in investing time to support Etch development and
>> use it as a key component in multiple products. It is also expected
>> that non-Cisco developers will become interested in Etch.
>>
>> === Relationships with Other Apache Products ===
>>
>> Etch currently depends upon these other Apache projects: Velocity,
>> Maven and Ant.
>>
>> We expect that as Etch becomes available, it will be seen as a very
>> compelling technology and others will begin to depend upon it.
>>
>> === A Excessive Fascination with the Apache Brand ===
>>
>> We believe Etch offers much to the Apache brand. We could easily, with
>> the backing of Cisco, take a more independent route and support Etch
>> directly without the Apache foundation. But after much consideration,
>> we truly believe that would be the wrong approach for this technology.
>>
>> As a technology, we believe Etch is very much a kindred spirit of the
>> other software infrastructure technologies currently part of the
>> Apache community: Ant, Velocity, Derby, and others. The technological
>> niche of Etch--platform and language agnostic service definition and
>> binding-is a technology that can be appreciated across a broad range
>> software domains.
>>
>> It is our view that Apache is simply the most appropriate community
>> for the kind of technology Etch represents.
>>
>> == Documentation ==
>>
>> Public documents are available. All documentation can be found here
>> http://developer.cisco.com/web/cuae/etch .
>>
>> == Initial Source ==
>>
>> Etch has been in development at Cisco since Jan-2007. The system was
>> designed from the beginning to be open-sourced.  We consider Etch to
>> be at release 1.0 and ready for production use.
>>
>> We continue to develop on Etch aggressively and a continually adding
>> tests and documentation to accompany the code, in particular around
>> Etch's unique pluggable architecture.
>>
>> The compiler and language bindings for Java and C# are working and
>> functional. Etch will be included in shipping Cisco products in
>> Sept-2008 as a core technology component.
>>
>> The language bindings for JavaScript, Python and C are in development.
>> The Etch development home page is currently hosted a Cisco's developer
>> portal: http://developer.cisco.com/web/cuae/etch . Full source and
>> binary distributions are available there including access to our
>> public subversion repository.
>>
>> == Source and Intellectual Property Submission Plan ==
>>
>> Apache would receive all source and documentation under the Apache
>> Corporate Contributor agreement. Cisco is the only license holder.
>>
>> == External Dependencies ==
>>
>> Java, JavaCC and Velocity are core dependencies of the compiler. The
>> Java language binding depends only on Java.
>>
>> Ant and Maven are used by the build system.
>>
>> For the other language bindings we have the following compile/link
>> dependencies:
>>
>> C# - Microsoft .NET v2.0 (Mono compatibility coming soon)
>>
>> == Cryptography ==
>>
>> Etch uses the native capabilities of Java and C# to support TLS as an
>> option for the default Etch binary transport protocol.
>>
>> == Required Resources ==
>>
>> === Mailing Lists ===
>>
>>  * etch-private
>>  * etch-dev
>>  * etch-commits
>>  * etch-user
>>
>> === Subversion Directory ===
>>
>>  https://svn.apache.org/repos/asf/incubator/etch
>>
>> === Issue Tracking ===
>>
>>  JIRA : Etch (ETCH)
>>
>> === Other Resources ===
>>
>>  None
>>
>> == Initial Committers ==
>>
>>
>> Gaurav Sandhir      gsandhir at cisco dot com
>>
>> J.D. Liau           jliau at cisco dot com
>>
>> James Dixson        jadixson at cisco dot com
>>
>> James deCocq      jadecocq at cisco dot com
>>
>> Rene Barazza        rebarraz at cisco dot com
>>
>> Scott Comer         sccomer at cisco dot com
>>
>> Seth Call           secall at cisco dot com
>>
>> Youngjin Park     youngjpa at cisco dot com
>>
>> === Affiliations ===
>>
>> All the initial committers are Cisco employees.
>>
>> == Sponsors ==
>>
>> === Champion ===
>>
>> Niclas Hedhman (has offered to be Champion)
>>
>> === Nominated Mentors ===
>>
>> Niclas Hedhman
>>
>> Doug Cutting
>>
>> Yonik Seeley
>>
>> === Sponsoring Entity ===
>>
>> Incubator
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>



-- 
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair

blog: http://pzf.fremantle.org
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com

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

Re: [VOTE] accept Etch into the Incubator

[ant elder <an...@gmail.com>]

+1

   ...ant

On Mon, Aug 25, 2008 at 7:09 PM, Yonik Seeley <yo...@apache.org> wrote:

> Since wiki pages can change, the full text of the proposal needs to be
> in the vote thread.
> Here is the text of the proposal:
>
> == Abstract ==
>
> Etch is a cross-platform, language- and transport-independent
> framework for building and consuming network services.
>
> == Proposal ==
>
> Etch is a cross-platform, language- and transport-independent
> framework for building and consuming network services. The Etch
> toolset includes a network service description language, a compiler,
> and binding libraries for a variety of programming languages. Etch is
> also transport-independent, allowing for a variety of different
> transports to used based on need and circumstance. The goal of Etch is
> to make it simple to define small, focused services that can be easily
> accessed, combined, and deployed in a similar manner. Ultimately with
> Etch, service development and consumption becomes no more difficult
> than library development and consumption.
>
> == Background ==
>
> Etch was started because we wanted to have a way to write a concise,
> formal description of the message exchange between a client and a
> server, with that message exchange supporting a hefty set of
> requirements. The messaging technology should support one-way and
> two-way, real-time communication. It should have high performance and
> scalability. I should support clients and servers written in different
> languages. It should also support clients/servers running in a wide
> range of contexts (such as thin web client, embedded device, PC
> application, or server). It must support anyone adding new language
> bindings and new transports. It should also be fast and small, while
> still being flexible enough to satisfy requirements. Finally, it must
> be easy to use for developers both implementing and/or consuming the
> service.
>
> == Rationale ==
>
> Existing systems were either too slow, hard to use, bloated and/or
> proprietary. In any case, none fit our matrix of requirements
> perfectly.
>
> Developers of applications that must leverage the capabilities of
> network-hosted services have a daunting challenge. They must cobble
> together a heterogeneous collection of services that expose different
> APIs with different communications technologies just to integrate with
> the services, essentially spending a great deal of energy and effort
> on just the basics of inter-service communication rather than core
> business logic.
>
> So the desired state then is when developing applications that
> leverage the capabilities of dispersed and heterogeneous network
> services, APIs must be simple, cohesive, and coherent across network
> services. APIs should be easy to consume by developers regardless of
> the implementation technology of the service used or the domain a
> service is being built within- from client-side web applications to
> complex real-time server systems. Put simply, developers ideally
> should feel that they are developing to a platform.
>
> API development is a much better understood and simpler subject if you
> are building those APIs to be run _locally_ on a single machine or
> service. Microsoft and Linux centric API developers have the luxury of
> the massive assumption that a standard OS is available with a certain
> set of features, and the API libraries do not have to take into
> account the complexities of APIs that cross machine or OS boundaries.
>
> Developers of network-centered services, rather than OS-centered
> services, do not have this luxury; we have a significant set of issues
> facing us today because of the fundamental fact that "the network" is
> not a single machine, or a homogeneous set of machines, but a
> heterogeneous and widely distributed set of services.
>
> The conventional method for developers of network services today is to
> use either a technology specific to the language of preference, RMI
> for Java, .NET Remoting for .NET for C#, etc., or if trying to be
> "language neutral" picking a CORBA ORB or a Web Service technology
> like SOAP or REST. These choices are fine until the requirements of
> the application cannot accept the limitations of the remoting
> technology. If the application needs to work on non-Microsoft
> platforms, .NET Remoting is out (unless, of course, you can use the
> Mono implementation of .NET, but that brings with it other
> challenges). If the need is to support access from languages other
> than Java, then RMI is out. If the need includes support for
> real-time, asynchronous communication, or symmetric two-way
> communications, the Web services technologies must also be rejected.
>
> For other classes of applications, there are simply no "standard"
> choices left. The developer is forced to drop down to a network
> protocol level and invent a new messaging system for their needs.
> Building a protocol by hand is hard; building a messaging system is
> also hard. This dramatically increases the barrier to entry for new,
> useful applications that leverage network-services.
>
> An orthogonal problem exists when supporting more than one transport
> technology is required of the application, e.g. HTTP/SOAP and
> HTTP/REST or HTTP/SOAP and a proprietary service protocol. This is
> also burdensome to the developer because now two or more distinct
> technologies must be used to expose the same interface. This typically
> means the development and maintenance of parallel implementations of
> the service using the technologies native to the transport mechanism.
> Often the result here is that one interface is the complete interface,
> while others suffer from various levels of partial or out-of-sync
> implementation.
>
> What if this was the reality instead: every interface to a network
> service could be had via a single, common API technology that 'just
> works' in every major language (C#, Java, Python, Ruby, C or even
> Javascript in a browser). What if this technology could produce the
> native stub code needed to do the networking and message passing (much
> like Web Services). Then the developer could concentrate on the
> business logic of the application or service rather than the
> idiosyncrasies of the network plumbing.
>
> As a language and transport independent network API generator, Etch
> can provide programmers with a consistent API model to program against
> while giving them the ability to redeploy into a variety of languages
> or transports at runtime (per developer/customer choice). So, one may
> use the same API implementation to send messages using an XML coding
> on a stream protocol in Java, or binary coding wrapped in reliable UDP
> in C#, or a shared memory queue on a router backplane in C, or even
> Python over SOAP. One could, in fact, support all at the same time,
> and any others that you care to implement or find, as long as you
> support the required semantics of the API.
>
> It all comes down to this: developers should not have to care about
> the implementation language or platform of the service nor what the
> transport is to get there, as long as basic semantics are honored, and
> these should be no more or less than the semantics of your programming
> language of choice. Further, a user requirement about specific
> protocols should not require rewriting of application logic to make it
> fit into some arbitrary framework scheme or container.
>
> == Current Status ==
>
> === Meritocracy ===
>
> Etch was conceived by Scott Comer and Louis Marascio. As Scott
> finished the development of the core compiler and first transport
> implementation, others have made various contributions to the project:
> James Dixson and Shawn Dempsey have worked on the build environment;
> Manoj Ganesan has worked on a Ruby binding; James Dixson on the Python
> binding; and James deCocq on the C binding; Manoj Ganesan and Gaurav
> Sandhir did primary work on C# and maintenance work all around. J.D.
> Liau has been instrumental in ideas and maintenance. Hung Nguyen has
> created the Windows installer using NSIS and Seth Call is working on a
> JavaScript binding with JSON transport for thin clients.
>
> === Community ===
>
> Etch solves problems lots of projects have. Any project that has a
> need to define multiple services in a consistent way, or expose
> services on the network to a variety of languages or platforms can
> benefit from Etch as technology.
>
> === Core Developers ===
>
>
> The core developers are all listed in the initial committers list
> later in this proposal.
>
> === Alignment ===
>
> The compiler code is in Java, but the technology is language- and
> protocol-agnostic and suitable for many different projects, including
> non-Java. The compiler makes use of Apache Ant for orchestrating the
> build, and Apache Velocity for code generation.
>
> == Known Risks ==
>
> === Orphaned Products ===
>
> We are all quite committed to Etch and the development of an Etch
> community. Etch is a core component of shipping Cisco products and
> will only grow over time.
>
> Our employer is also committed to the success of the technology,
> allowing us to continue to invest our time in support of Etch
> development as well as committing to Etch technology as a key
> component in multiple products.
>
> Etch being orphaned is unlikely.
>
> === Inexperience with Open Source ===
>
> The group of initial committers has had various levels of interaction
> with open-source communities. Most of us came into Cisco through the
> acquisition of Metreos in 2006. While at Metreos, Louis Marascio and
> several of us were active contributor's to the OpenH323 project. We
> worked through several bugs, submitted patches and even sponsored
> development. We have also made contributions to other projects (some
> accepted, some not) on a much smaller scale over the years, QDox,
> Maruku, Capistrano, OpenGatekeeper, and Mono.
>
> === Homogeneous Developers ===
>
> Etch has been completely developed by Cisco employees, therefore all
> of the initial committers to the project are affiliated with Cisco.
>
> Etch has just recently been made publicly available. First in binary
> form in May 2008 as part of a Cisco product and in open source form in
> July 2008.
>
> === Reliance on Salaried Developers ===
>
> It is expected that Etch development will be done both on salaried
> time and volunteer time. Cisco is highly interested in the success and
> development of an Etch community. At this time, Etch is a core
> component of shipping Cisco products and is likely to grow over time.
> Cisco in interested in investing time to support Etch development and
> use it as a key component in multiple products. It is also expected
> that non-Cisco developers will become interested in Etch.
>
> === Relationships with Other Apache Products ===
>
> Etch currently depends upon these other Apache projects: Velocity,
> Maven and Ant.
>
> We expect that as Etch becomes available, it will be seen as a very
> compelling technology and others will begin to depend upon it.
>
> === A Excessive Fascination with the Apache Brand ===
>
> We believe Etch offers much to the Apache brand. We could easily, with
> the backing of Cisco, take a more independent route and support Etch
> directly without the Apache foundation. But after much consideration,
> we truly believe that would be the wrong approach for this technology.
>
> As a technology, we believe Etch is very much a kindred spirit of the
> other software infrastructure technologies currently part of the
> Apache community: Ant, Velocity, Derby, and others. The technological
> niche of Etch--platform and language agnostic service definition and
> binding-is a technology that can be appreciated across a broad range
> software domains.
>
> It is our view that Apache is simply the most appropriate community
> for the kind of technology Etch represents.
>
> == Documentation ==
>
> Public documents are available. All documentation can be found here
> http://developer.cisco.com/web/cuae/etch .
>
> == Initial Source ==
>
> Etch has been in development at Cisco since Jan-2007. The system was
> designed from the beginning to be open-sourced.  We consider Etch to
> be at release 1.0 and ready for production use.
>
> We continue to develop on Etch aggressively and a continually adding
> tests and documentation to accompany the code, in particular around
> Etch's unique pluggable architecture.
>
> The compiler and language bindings for Java and C# are working and
> functional. Etch will be included in shipping Cisco products in
> Sept-2008 as a core technology component.
>
> The language bindings for JavaScript, Python and C are in development.
> The Etch development home page is currently hosted a Cisco's developer
> portal: http://developer.cisco.com/web/cuae/etch . Full source and
> binary distributions are available there including access to our
> public subversion repository.
>
> == Source and Intellectual Property Submission Plan ==
>
> Apache would receive all source and documentation under the Apache
> Corporate Contributor agreement. Cisco is the only license holder.
>
> == External Dependencies ==
>
> Java, JavaCC and Velocity are core dependencies of the compiler. The
> Java language binding depends only on Java.
>
> Ant and Maven are used by the build system.
>
> For the other language bindings we have the following compile/link
> dependencies:
>
> C# - Microsoft .NET v2.0 (Mono compatibility coming soon)
>
> == Cryptography ==
>
> Etch uses the native capabilities of Java and C# to support TLS as an
> option for the default Etch binary transport protocol.
>
> == Required Resources ==
>
> === Mailing Lists ===
>
>  * etch-private
>  * etch-dev
>  * etch-commits
>  * etch-user
>
> === Subversion Directory ===
>
>  https://svn.apache.org/repos/asf/incubator/etch
>
> === Issue Tracking ===
>
>  JIRA : Etch (ETCH)
>
> === Other Resources ===
>
>  None
>
> == Initial Committers ==
>
>
> Gaurav Sandhir      gsandhir at cisco dot com
>
> J.D. Liau           jliau at cisco dot com
>
> James Dixson        jadixson at cisco dot com
>
> James deCocq      jadecocq at cisco dot com
>
> Rene Barazza        rebarraz at cisco dot com
>
> Scott Comer         sccomer at cisco dot com
>
> Seth Call           secall at cisco dot com
>
> Youngjin Park     youngjpa at cisco dot com
>
> === Affiliations ===
>
> All the initial committers are Cisco employees.
>
> == Sponsors ==
>
> === Champion ===
>
> Niclas Hedhman (has offered to be Champion)
>
> === Nominated Mentors ===
>
> Niclas Hedhman
>
> Doug Cutting
>
> Yonik Seeley
>
> === Sponsoring Entity ===
>
> Incubator
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: [VOTE] accept Etch into the Incubator

[Robert Burrell Donkin <ro...@gmail.com>]

+1

- robert

On Mon, Aug 25, 2008 at 7:09 PM, Yonik Seeley <yo...@apache.org> wrote:
> Since wiki pages can change, the full text of the proposal needs to be
> in the vote thread.
> Here is the text of the proposal:
>
> == Abstract ==
>
> Etch is a cross-platform, language- and transport-independent
> framework for building and consuming network services.
>
> == Proposal ==
>
> Etch is a cross-platform, language- and transport-independent
> framework for building and consuming network services. The Etch
> toolset includes a network service description language, a compiler,
> and binding libraries for a variety of programming languages. Etch is
> also transport-independent, allowing for a variety of different
> transports to used based on need and circumstance. The goal of Etch is
> to make it simple to define small, focused services that can be easily
> accessed, combined, and deployed in a similar manner. Ultimately with
> Etch, service development and consumption becomes no more difficult
> than library development and consumption.
>
> == Background ==
>
> Etch was started because we wanted to have a way to write a concise,
> formal description of the message exchange between a client and a
> server, with that message exchange supporting a hefty set of
> requirements. The messaging technology should support one-way and
> two-way, real-time communication. It should have high performance and
> scalability. I should support clients and servers written in different
> languages. It should also support clients/servers running in a wide
> range of contexts (such as thin web client, embedded device, PC
> application, or server). It must support anyone adding new language
> bindings and new transports. It should also be fast and small, while
> still being flexible enough to satisfy requirements. Finally, it must
> be easy to use for developers both implementing and/or consuming the
> service.
>
> == Rationale ==
>
> Existing systems were either too slow, hard to use, bloated and/or
> proprietary. In any case, none fit our matrix of requirements
> perfectly.
>
> Developers of applications that must leverage the capabilities of
> network-hosted services have a daunting challenge. They must cobble
> together a heterogeneous collection of services that expose different
> APIs with different communications technologies just to integrate with
> the services, essentially spending a great deal of energy and effort
> on just the basics of inter-service communication rather than core
> business logic.
>
> So the desired state then is when developing applications that
> leverage the capabilities of dispersed and heterogeneous network
> services, APIs must be simple, cohesive, and coherent across network
> services. APIs should be easy to consume by developers regardless of
> the implementation technology of the service used or the domain a
> service is being built within- from client-side web applications to
> complex real-time server systems. Put simply, developers ideally
> should feel that they are developing to a platform.
>
> API development is a much better understood and simpler subject if you
> are building those APIs to be run _locally_ on a single machine or
> service. Microsoft and Linux centric API developers have the luxury of
> the massive assumption that a standard OS is available with a certain
> set of features, and the API libraries do not have to take into
> account the complexities of APIs that cross machine or OS boundaries.
>
> Developers of network-centered services, rather than OS-centered
> services, do not have this luxury; we have a significant set of issues
> facing us today because of the fundamental fact that "the network" is
> not a single machine, or a homogeneous set of machines, but a
> heterogeneous and widely distributed set of services.
>
> The conventional method for developers of network services today is to
> use either a technology specific to the language of preference, RMI
> for Java, .NET Remoting for .NET for C#, etc., or if trying to be
> "language neutral" picking a CORBA ORB or a Web Service technology
> like SOAP or REST. These choices are fine until the requirements of
> the application cannot accept the limitations of the remoting
> technology. If the application needs to work on non-Microsoft
> platforms, .NET Remoting is out (unless, of course, you can use the
> Mono implementation of .NET, but that brings with it other
> challenges). If the need is to support access from languages other
> than Java, then RMI is out. If the need includes support for
> real-time, asynchronous communication, or symmetric two-way
> communications, the Web services technologies must also be rejected.
>
> For other classes of applications, there are simply no "standard"
> choices left. The developer is forced to drop down to a network
> protocol level and invent a new messaging system for their needs.
> Building a protocol by hand is hard; building a messaging system is
> also hard. This dramatically increases the barrier to entry for new,
> useful applications that leverage network-services.
>
> An orthogonal problem exists when supporting more than one transport
> technology is required of the application, e.g. HTTP/SOAP and
> HTTP/REST or HTTP/SOAP and a proprietary service protocol. This is
> also burdensome to the developer because now two or more distinct
> technologies must be used to expose the same interface. This typically
> means the development and maintenance of parallel implementations of
> the service using the technologies native to the transport mechanism.
> Often the result here is that one interface is the complete interface,
> while others suffer from various levels of partial or out-of-sync
> implementation.
>
> What if this was the reality instead: every interface to a network
> service could be had via a single, common API technology that 'just
> works' in every major language (C#, Java, Python, Ruby, C or even
> Javascript in a browser). What if this technology could produce the
> native stub code needed to do the networking and message passing (much
> like Web Services). Then the developer could concentrate on the
> business logic of the application or service rather than the
> idiosyncrasies of the network plumbing.
>
> As a language and transport independent network API generator, Etch
> can provide programmers with a consistent API model to program against
> while giving them the ability to redeploy into a variety of languages
> or transports at runtime (per developer/customer choice). So, one may
> use the same API implementation to send messages using an XML coding
> on a stream protocol in Java, or binary coding wrapped in reliable UDP
> in C#, or a shared memory queue on a router backplane in C, or even
> Python over SOAP. One could, in fact, support all at the same time,
> and any others that you care to implement or find, as long as you
> support the required semantics of the API.
>
> It all comes down to this: developers should not have to care about
> the implementation language or platform of the service nor what the
> transport is to get there, as long as basic semantics are honored, and
> these should be no more or less than the semantics of your programming
> language of choice. Further, a user requirement about specific
> protocols should not require rewriting of application logic to make it
> fit into some arbitrary framework scheme or container.
>
> == Current Status ==
>
> === Meritocracy ===
>
> Etch was conceived by Scott Comer and Louis Marascio. As Scott
> finished the development of the core compiler and first transport
> implementation, others have made various contributions to the project:
> James Dixson and Shawn Dempsey have worked on the build environment;
> Manoj Ganesan has worked on a Ruby binding; James Dixson on the Python
> binding; and James deCocq on the C binding; Manoj Ganesan and Gaurav
> Sandhir did primary work on C# and maintenance work all around. J.D.
> Liau has been instrumental in ideas and maintenance. Hung Nguyen has
> created the Windows installer using NSIS and Seth Call is working on a
> JavaScript binding with JSON transport for thin clients.
>
> === Community ===
>
> Etch solves problems lots of projects have. Any project that has a
> need to define multiple services in a consistent way, or expose
> services on the network to a variety of languages or platforms can
> benefit from Etch as technology.
>
> === Core Developers ===
>
>
> The core developers are all listed in the initial committers list
> later in this proposal.
>
> === Alignment ===
>
> The compiler code is in Java, but the technology is language- and
> protocol-agnostic and suitable for many different projects, including
> non-Java. The compiler makes use of Apache Ant for orchestrating the
> build, and Apache Velocity for code generation.
>
> == Known Risks ==
>
> === Orphaned Products ===
>
> We are all quite committed to Etch and the development of an Etch
> community. Etch is a core component of shipping Cisco products and
> will only grow over time.
>
> Our employer is also committed to the success of the technology,
> allowing us to continue to invest our time in support of Etch
> development as well as committing to Etch technology as a key
> component in multiple products.
>
> Etch being orphaned is unlikely.
>
> === Inexperience with Open Source ===
>
> The group of initial committers has had various levels of interaction
> with open-source communities. Most of us came into Cisco through the
> acquisition of Metreos in 2006. While at Metreos, Louis Marascio and
> several of us were active contributor's to the OpenH323 project. We
> worked through several bugs, submitted patches and even sponsored
> development. We have also made contributions to other projects (some
> accepted, some not) on a much smaller scale over the years, QDox,
> Maruku, Capistrano, OpenGatekeeper, and Mono.
>
> === Homogeneous Developers ===
>
> Etch has been completely developed by Cisco employees, therefore all
> of the initial committers to the project are affiliated with Cisco.
>
> Etch has just recently been made publicly available. First in binary
> form in May 2008 as part of a Cisco product and in open source form in
> July 2008.
>
> === Reliance on Salaried Developers ===
>
> It is expected that Etch development will be done both on salaried
> time and volunteer time. Cisco is highly interested in the success and
> development of an Etch community. At this time, Etch is a core
> component of shipping Cisco products and is likely to grow over time.
> Cisco in interested in investing time to support Etch development and
> use it as a key component in multiple products. It is also expected
> that non-Cisco developers will become interested in Etch.
>
> === Relationships with Other Apache Products ===
>
> Etch currently depends upon these other Apache projects: Velocity,
> Maven and Ant.
>
> We expect that as Etch becomes available, it will be seen as a very
> compelling technology and others will begin to depend upon it.
>
> === A Excessive Fascination with the Apache Brand ===
>
> We believe Etch offers much to the Apache brand. We could easily, with
> the backing of Cisco, take a more independent route and support Etch
> directly without the Apache foundation. But after much consideration,
> we truly believe that would be the wrong approach for this technology.
>
> As a technology, we believe Etch is very much a kindred spirit of the
> other software infrastructure technologies currently part of the
> Apache community: Ant, Velocity, Derby, and others. The technological
> niche of Etch--platform and language agnostic service definition and
> binding-is a technology that can be appreciated across a broad range
> software domains.
>
> It is our view that Apache is simply the most appropriate community
> for the kind of technology Etch represents.
>
> == Documentation ==
>
> Public documents are available. All documentation can be found here
> http://developer.cisco.com/web/cuae/etch .
>
> == Initial Source ==
>
> Etch has been in development at Cisco since Jan-2007. The system was
> designed from the beginning to be open-sourced.  We consider Etch to
> be at release 1.0 and ready for production use.
>
> We continue to develop on Etch aggressively and a continually adding
> tests and documentation to accompany the code, in particular around
> Etch's unique pluggable architecture.
>
> The compiler and language bindings for Java and C# are working and
> functional. Etch will be included in shipping Cisco products in
> Sept-2008 as a core technology component.
>
> The language bindings for JavaScript, Python and C are in development.
> The Etch development home page is currently hosted a Cisco's developer
> portal: http://developer.cisco.com/web/cuae/etch . Full source and
> binary distributions are available there including access to our
> public subversion repository.
>
> == Source and Intellectual Property Submission Plan ==
>
> Apache would receive all source and documentation under the Apache
> Corporate Contributor agreement. Cisco is the only license holder.
>
> == External Dependencies ==
>
> Java, JavaCC and Velocity are core dependencies of the compiler. The
> Java language binding depends only on Java.
>
> Ant and Maven are used by the build system.
>
> For the other language bindings we have the following compile/link dependencies:
>
> C# - Microsoft .NET v2.0 (Mono compatibility coming soon)
>
> == Cryptography ==
>
> Etch uses the native capabilities of Java and C# to support TLS as an
> option for the default Etch binary transport protocol.
>
> == Required Resources ==
>
> === Mailing Lists ===
>
>  * etch-private
>  * etch-dev
>  * etch-commits
>  * etch-user
>
> === Subversion Directory ===
>
>  https://svn.apache.org/repos/asf/incubator/etch
>
> === Issue Tracking ===
>
>  JIRA : Etch (ETCH)
>
> === Other Resources ===
>
>  None
>
> == Initial Committers ==
>
>
> Gaurav Sandhir      gsandhir at cisco dot com
>
> J.D. Liau           jliau at cisco dot com
>
> James Dixson        jadixson at cisco dot com
>
> James deCocq      jadecocq at cisco dot com
>
> Rene Barazza        rebarraz at cisco dot com
>
> Scott Comer         sccomer at cisco dot com
>
> Seth Call           secall at cisco dot com
>
> Youngjin Park     youngjpa at cisco dot com
>
> === Affiliations ===
>
> All the initial committers are Cisco employees.
>
> == Sponsors ==
>
> === Champion ===
>
> Niclas Hedhman (has offered to be Champion)
>
> === Nominated Mentors ===
>
> Niclas Hedhman
>
> Doug Cutting
>
> Yonik Seeley
>
> === Sponsoring Entity ===
>
> Incubator
>
> ---------------------------------------------------------------------
> 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

Re: [VOTE] accept Etch into the Incubator

[Niclas Hedhman <ni...@hedhman.org>]

+1 (binding)

Cheers
Niclas

On Mon, Aug 25, 2008 at 8:09 PM, Yonik Seeley <yo...@apache.org> wrote:
> Since wiki pages can change, the full text of the proposal needs to be
> in the vote thread.
> Here is the text of the proposal:
>
> == Abstract ==
>
> Etch is a cross-platform, language- and transport-independent
> framework for building and consuming network services.
>
> == Proposal ==
>
> Etch is a cross-platform, language- and transport-independent
> framework for building and consuming network services. The Etch
> toolset includes a network service description language, a compiler,
> and binding libraries for a variety of programming languages. Etch is
> also transport-independent, allowing for a variety of different
> transports to used based on need and circumstance. The goal of Etch is
> to make it simple to define small, focused services that can be easily
> accessed, combined, and deployed in a similar manner. Ultimately with
> Etch, service development and consumption becomes no more difficult
> than library development and consumption.
>
> == Background ==
>
> Etch was started because we wanted to have a way to write a concise,
> formal description of the message exchange between a client and a
> server, with that message exchange supporting a hefty set of
> requirements. The messaging technology should support one-way and
> two-way, real-time communication. It should have high performance and
> scalability. I should support clients and servers written in different
> languages. It should also support clients/servers running in a wide
> range of contexts (such as thin web client, embedded device, PC
> application, or server). It must support anyone adding new language
> bindings and new transports. It should also be fast and small, while
> still being flexible enough to satisfy requirements. Finally, it must
> be easy to use for developers both implementing and/or consuming the
> service.
>
> == Rationale ==
>
> Existing systems were either too slow, hard to use, bloated and/or
> proprietary. In any case, none fit our matrix of requirements
> perfectly.
>
> Developers of applications that must leverage the capabilities of
> network-hosted services have a daunting challenge. They must cobble
> together a heterogeneous collection of services that expose different
> APIs with different communications technologies just to integrate with
> the services, essentially spending a great deal of energy and effort
> on just the basics of inter-service communication rather than core
> business logic.
>
> So the desired state then is when developing applications that
> leverage the capabilities of dispersed and heterogeneous network
> services, APIs must be simple, cohesive, and coherent across network
> services. APIs should be easy to consume by developers regardless of
> the implementation technology of the service used or the domain a
> service is being built within- from client-side web applications to
> complex real-time server systems. Put simply, developers ideally
> should feel that they are developing to a platform.
>
> API development is a much better understood and simpler subject if you
> are building those APIs to be run _locally_ on a single machine or
> service. Microsoft and Linux centric API developers have the luxury of
> the massive assumption that a standard OS is available with a certain
> set of features, and the API libraries do not have to take into
> account the complexities of APIs that cross machine or OS boundaries.
>
> Developers of network-centered services, rather than OS-centered
> services, do not have this luxury; we have a significant set of issues
> facing us today because of the fundamental fact that "the network" is
> not a single machine, or a homogeneous set of machines, but a
> heterogeneous and widely distributed set of services.
>
> The conventional method for developers of network services today is to
> use either a technology specific to the language of preference, RMI
> for Java, .NET Remoting for .NET for C#, etc., or if trying to be
> "language neutral" picking a CORBA ORB or a Web Service technology
> like SOAP or REST. These choices are fine until the requirements of
> the application cannot accept the limitations of the remoting
> technology. If the application needs to work on non-Microsoft
> platforms, .NET Remoting is out (unless, of course, you can use the
> Mono implementation of .NET, but that brings with it other
> challenges). If the need is to support access from languages other
> than Java, then RMI is out. If the need includes support for
> real-time, asynchronous communication, or symmetric two-way
> communications, the Web services technologies must also be rejected.
>
> For other classes of applications, there are simply no "standard"
> choices left. The developer is forced to drop down to a network
> protocol level and invent a new messaging system for their needs.
> Building a protocol by hand is hard; building a messaging system is
> also hard. This dramatically increases the barrier to entry for new,
> useful applications that leverage network-services.
>
> An orthogonal problem exists when supporting more than one transport
> technology is required of the application, e.g. HTTP/SOAP and
> HTTP/REST or HTTP/SOAP and a proprietary service protocol. This is
> also burdensome to the developer because now two or more distinct
> technologies must be used to expose the same interface. This typically
> means the development and maintenance of parallel implementations of
> the service using the technologies native to the transport mechanism.
> Often the result here is that one interface is the complete interface,
> while others suffer from various levels of partial or out-of-sync
> implementation.
>
> What if this was the reality instead: every interface to a network
> service could be had via a single, common API technology that 'just
> works' in every major language (C#, Java, Python, Ruby, C or even
> Javascript in a browser). What if this technology could produce the
> native stub code needed to do the networking and message passing (much
> like Web Services). Then the developer could concentrate on the
> business logic of the application or service rather than the
> idiosyncrasies of the network plumbing.
>
> As a language and transport independent network API generator, Etch
> can provide programmers with a consistent API model to program against
> while giving them the ability to redeploy into a variety of languages
> or transports at runtime (per developer/customer choice). So, one may
> use the same API implementation to send messages using an XML coding
> on a stream protocol in Java, or binary coding wrapped in reliable UDP
> in C#, or a shared memory queue on a router backplane in C, or even
> Python over SOAP. One could, in fact, support all at the same time,
> and any others that you care to implement or find, as long as you
> support the required semantics of the API.
>
> It all comes down to this: developers should not have to care about
> the implementation language or platform of the service nor what the
> transport is to get there, as long as basic semantics are honored, and
> these should be no more or less than the semantics of your programming
> language of choice. Further, a user requirement about specific
> protocols should not require rewriting of application logic to make it
> fit into some arbitrary framework scheme or container.
>
> == Current Status ==
>
> === Meritocracy ===
>
> Etch was conceived by Scott Comer and Louis Marascio. As Scott
> finished the development of the core compiler and first transport
> implementation, others have made various contributions to the project:
> James Dixson and Shawn Dempsey have worked on the build environment;
> Manoj Ganesan has worked on a Ruby binding; James Dixson on the Python
> binding; and James deCocq on the C binding; Manoj Ganesan and Gaurav
> Sandhir did primary work on C# and maintenance work all around. J.D.
> Liau has been instrumental in ideas and maintenance. Hung Nguyen has
> created the Windows installer using NSIS and Seth Call is working on a
> JavaScript binding with JSON transport for thin clients.
>
> === Community ===
>
> Etch solves problems lots of projects have. Any project that has a
> need to define multiple services in a consistent way, or expose
> services on the network to a variety of languages or platforms can
> benefit from Etch as technology.
>
> === Core Developers ===
>
>
> The core developers are all listed in the initial committers list
> later in this proposal.
>
> === Alignment ===
>
> The compiler code is in Java, but the technology is language- and
> protocol-agnostic and suitable for many different projects, including
> non-Java. The compiler makes use of Apache Ant for orchestrating the
> build, and Apache Velocity for code generation.
>
> == Known Risks ==
>
> === Orphaned Products ===
>
> We are all quite committed to Etch and the development of an Etch
> community. Etch is a core component of shipping Cisco products and
> will only grow over time.
>
> Our employer is also committed to the success of the technology,
> allowing us to continue to invest our time in support of Etch
> development as well as committing to Etch technology as a key
> component in multiple products.
>
> Etch being orphaned is unlikely.
>
> === Inexperience with Open Source ===
>
> The group of initial committers has had various levels of interaction
> with open-source communities. Most of us came into Cisco through the
> acquisition of Metreos in 2006. While at Metreos, Louis Marascio and
> several of us were active contributor's to the OpenH323 project. We
> worked through several bugs, submitted patches and even sponsored
> development. We have also made contributions to other projects (some
> accepted, some not) on a much smaller scale over the years, QDox,
> Maruku, Capistrano, OpenGatekeeper, and Mono.
>
> === Homogeneous Developers ===
>
> Etch has been completely developed by Cisco employees, therefore all
> of the initial committers to the project are affiliated with Cisco.
>
> Etch has just recently been made publicly available. First in binary
> form in May 2008 as part of a Cisco product and in open source form in
> July 2008.
>
> === Reliance on Salaried Developers ===
>
> It is expected that Etch development will be done both on salaried
> time and volunteer time. Cisco is highly interested in the success and
> development of an Etch community. At this time, Etch is a core
> component of shipping Cisco products and is likely to grow over time.
> Cisco in interested in investing time to support Etch development and
> use it as a key component in multiple products. It is also expected
> that non-Cisco developers will become interested in Etch.
>
> === Relationships with Other Apache Products ===
>
> Etch currently depends upon these other Apache projects: Velocity,
> Maven and Ant.
>
> We expect that as Etch becomes available, it will be seen as a very
> compelling technology and others will begin to depend upon it.
>
> === A Excessive Fascination with the Apache Brand ===
>
> We believe Etch offers much to the Apache brand. We could easily, with
> the backing of Cisco, take a more independent route and support Etch
> directly without the Apache foundation. But after much consideration,
> we truly believe that would be the wrong approach for this technology.
>
> As a technology, we believe Etch is very much a kindred spirit of the
> other software infrastructure technologies currently part of the
> Apache community: Ant, Velocity, Derby, and others. The technological
> niche of Etch--platform and language agnostic service definition and
> binding-is a technology that can be appreciated across a broad range
> software domains.
>
> It is our view that Apache is simply the most appropriate community
> for the kind of technology Etch represents.
>
> == Documentation ==
>
> Public documents are available. All documentation can be found here
> http://developer.cisco.com/web/cuae/etch .
>
> == Initial Source ==
>
> Etch has been in development at Cisco since Jan-2007. The system was
> designed from the beginning to be open-sourced.  We consider Etch to
> be at release 1.0 and ready for production use.
>
> We continue to develop on Etch aggressively and a continually adding
> tests and documentation to accompany the code, in particular around
> Etch's unique pluggable architecture.
>
> The compiler and language bindings for Java and C# are working and
> functional. Etch will be included in shipping Cisco products in
> Sept-2008 as a core technology component.
>
> The language bindings for JavaScript, Python and C are in development.
> The Etch development home page is currently hosted a Cisco's developer
> portal: http://developer.cisco.com/web/cuae/etch . Full source and
> binary distributions are available there including access to our
> public subversion repository.
>
> == Source and Intellectual Property Submission Plan ==
>
> Apache would receive all source and documentation under the Apache
> Corporate Contributor agreement. Cisco is the only license holder.
>
> == External Dependencies ==
>
> Java, JavaCC and Velocity are core dependencies of the compiler. The
> Java language binding depends only on Java.
>
> Ant and Maven are used by the build system.
>
> For the other language bindings we have the following compile/link dependencies:
>
> C# - Microsoft .NET v2.0 (Mono compatibility coming soon)
>
> == Cryptography ==
>
> Etch uses the native capabilities of Java and C# to support TLS as an
> option for the default Etch binary transport protocol.
>
> == Required Resources ==
>
> === Mailing Lists ===
>
>  * etch-private
>  * etch-dev
>  * etch-commits
>  * etch-user
>
> === Subversion Directory ===
>
>  https://svn.apache.org/repos/asf/incubator/etch
>
> === Issue Tracking ===
>
>  JIRA : Etch (ETCH)
>
> === Other Resources ===
>
>  None
>
> == Initial Committers ==
>
>
> Gaurav Sandhir      gsandhir at cisco dot com
>
> J.D. Liau           jliau at cisco dot com
>
> James Dixson        jadixson at cisco dot com
>
> James deCocq      jadecocq at cisco dot com
>
> Rene Barazza        rebarraz at cisco dot com
>
> Scott Comer         sccomer at cisco dot com
>
> Seth Call           secall at cisco dot com
>
> Youngjin Park     youngjpa at cisco dot com
>
> === Affiliations ===
>
> All the initial committers are Cisco employees.
>
> == Sponsors ==
>
> === Champion ===
>
> Niclas Hedhman (has offered to be Champion)
>
> === Nominated Mentors ===
>
> Niclas Hedhman
>
> Doug Cutting
>
> Yonik Seeley
>
> === Sponsoring Entity ===
>
> Incubator
>
> ---------------------------------------------------------------------
> 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

Re: [VOTE] accept Etch into the Incubator

[Craig L Russell <Cr...@Sun.COM>]

+1 for incubation.

Craig

On Aug 25, 2008, at 11:09 AM, Yonik Seeley wrote:

> Since wiki pages can change, the full text of the proposal needs to be
> in the vote thread.
> Here is the text of the proposal:
>
> == Abstract ==
>
> Etch is a cross-platform, language- and transport-independent
> framework for building and consuming network services.
>

Craig L Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

Re: [VOTE] accept Etch into the Incubator

[Martijn Dashorst <ma...@gmail.com>]

+1

On Mon, Aug 25, 2008 at 8:09 PM, Yonik Seeley <yo...@apache.org> wrote:
> Since wiki pages can change, the full text of the proposal needs to be
> in the vote thread.
> Here is the text of the proposal:
>
> == Abstract ==
>
> Etch is a cross-platform, language- and transport-independent
> framework for building and consuming network services.
>
> == Proposal ==
>
> Etch is a cross-platform, language- and transport-independent
> framework for building and consuming network services. The Etch
> toolset includes a network service description language, a compiler,
> and binding libraries for a variety of programming languages. Etch is
> also transport-independent, allowing for a variety of different
> transports to used based on need and circumstance. The goal of Etch is
> to make it simple to define small, focused services that can be easily
> accessed, combined, and deployed in a similar manner. Ultimately with
> Etch, service development and consumption becomes no more difficult
> than library development and consumption.
>
> == Background ==
>
> Etch was started because we wanted to have a way to write a concise,
> formal description of the message exchange between a client and a
> server, with that message exchange supporting a hefty set of
> requirements. The messaging technology should support one-way and
> two-way, real-time communication. It should have high performance and
> scalability. I should support clients and servers written in different
> languages. It should also support clients/servers running in a wide
> range of contexts (such as thin web client, embedded device, PC
> application, or server). It must support anyone adding new language
> bindings and new transports. It should also be fast and small, while
> still being flexible enough to satisfy requirements. Finally, it must
> be easy to use for developers both implementing and/or consuming the
> service.
>
> == Rationale ==
>
> Existing systems were either too slow, hard to use, bloated and/or
> proprietary. In any case, none fit our matrix of requirements
> perfectly.
>
> Developers of applications that must leverage the capabilities of
> network-hosted services have a daunting challenge. They must cobble
> together a heterogeneous collection of services that expose different
> APIs with different communications technologies just to integrate with
> the services, essentially spending a great deal of energy and effort
> on just the basics of inter-service communication rather than core
> business logic.
>
> So the desired state then is when developing applications that
> leverage the capabilities of dispersed and heterogeneous network
> services, APIs must be simple, cohesive, and coherent across network
> services. APIs should be easy to consume by developers regardless of
> the implementation technology of the service used or the domain a
> service is being built within- from client-side web applications to
> complex real-time server systems. Put simply, developers ideally
> should feel that they are developing to a platform.
>
> API development is a much better understood and simpler subject if you
> are building those APIs to be run _locally_ on a single machine or
> service. Microsoft and Linux centric API developers have the luxury of
> the massive assumption that a standard OS is available with a certain
> set of features, and the API libraries do not have to take into
> account the complexities of APIs that cross machine or OS boundaries.
>
> Developers of network-centered services, rather than OS-centered
> services, do not have this luxury; we have a significant set of issues
> facing us today because of the fundamental fact that "the network" is
> not a single machine, or a homogeneous set of machines, but a
> heterogeneous and widely distributed set of services.
>
> The conventional method for developers of network services today is to
> use either a technology specific to the language of preference, RMI
> for Java, .NET Remoting for .NET for C#, etc., or if trying to be
> "language neutral" picking a CORBA ORB or a Web Service technology
> like SOAP or REST. These choices are fine until the requirements of
> the application cannot accept the limitations of the remoting
> technology. If the application needs to work on non-Microsoft
> platforms, .NET Remoting is out (unless, of course, you can use the
> Mono implementation of .NET, but that brings with it other
> challenges). If the need is to support access from languages other
> than Java, then RMI is out. If the need includes support for
> real-time, asynchronous communication, or symmetric two-way
> communications, the Web services technologies must also be rejected.
>
> For other classes of applications, there are simply no "standard"
> choices left. The developer is forced to drop down to a network
> protocol level and invent a new messaging system for their needs.
> Building a protocol by hand is hard; building a messaging system is
> also hard. This dramatically increases the barrier to entry for new,
> useful applications that leverage network-services.
>
> An orthogonal problem exists when supporting more than one transport
> technology is required of the application, e.g. HTTP/SOAP and
> HTTP/REST or HTTP/SOAP and a proprietary service protocol. This is
> also burdensome to the developer because now two or more distinct
> technologies must be used to expose the same interface. This typically
> means the development and maintenance of parallel implementations of
> the service using the technologies native to the transport mechanism.
> Often the result here is that one interface is the complete interface,
> while others suffer from various levels of partial or out-of-sync
> implementation.
>
> What if this was the reality instead: every interface to a network
> service could be had via a single, common API technology that 'just
> works' in every major language (C#, Java, Python, Ruby, C or even
> Javascript in a browser). What if this technology could produce the
> native stub code needed to do the networking and message passing (much
> like Web Services). Then the developer could concentrate on the
> business logic of the application or service rather than the
> idiosyncrasies of the network plumbing.
>
> As a language and transport independent network API generator, Etch
> can provide programmers with a consistent API model to program against
> while giving them the ability to redeploy into a variety of languages
> or transports at runtime (per developer/customer choice). So, one may
> use the same API implementation to send messages using an XML coding
> on a stream protocol in Java, or binary coding wrapped in reliable UDP
> in C#, or a shared memory queue on a router backplane in C, or even
> Python over SOAP. One could, in fact, support all at the same time,
> and any others that you care to implement or find, as long as you
> support the required semantics of the API.
>
> It all comes down to this: developers should not have to care about
> the implementation language or platform of the service nor what the
> transport is to get there, as long as basic semantics are honored, and
> these should be no more or less than the semantics of your programming
> language of choice. Further, a user requirement about specific
> protocols should not require rewriting of application logic to make it
> fit into some arbitrary framework scheme or container.
>
> == Current Status ==
>
> === Meritocracy ===
>
> Etch was conceived by Scott Comer and Louis Marascio. As Scott
> finished the development of the core compiler and first transport
> implementation, others have made various contributions to the project:
> James Dixson and Shawn Dempsey have worked on the build environment;
> Manoj Ganesan has worked on a Ruby binding; James Dixson on the Python
> binding; and James deCocq on the C binding; Manoj Ganesan and Gaurav
> Sandhir did primary work on C# and maintenance work all around. J.D.
> Liau has been instrumental in ideas and maintenance. Hung Nguyen has
> created the Windows installer using NSIS and Seth Call is working on a
> JavaScript binding with JSON transport for thin clients.
>
> === Community ===
>
> Etch solves problems lots of projects have. Any project that has a
> need to define multiple services in a consistent way, or expose
> services on the network to a variety of languages or platforms can
> benefit from Etch as technology.
>
> === Core Developers ===
>
>
> The core developers are all listed in the initial committers list
> later in this proposal.
>
> === Alignment ===
>
> The compiler code is in Java, but the technology is language- and
> protocol-agnostic and suitable for many different projects, including
> non-Java. The compiler makes use of Apache Ant for orchestrating the
> build, and Apache Velocity for code generation.
>
> == Known Risks ==
>
> === Orphaned Products ===
>
> We are all quite committed to Etch and the development of an Etch
> community. Etch is a core component of shipping Cisco products and
> will only grow over time.
>
> Our employer is also committed to the success of the technology,
> allowing us to continue to invest our time in support of Etch
> development as well as committing to Etch technology as a key
> component in multiple products.
>
> Etch being orphaned is unlikely.
>
> === Inexperience with Open Source ===
>
> The group of initial committers has had various levels of interaction
> with open-source communities. Most of us came into Cisco through the
> acquisition of Metreos in 2006. While at Metreos, Louis Marascio and
> several of us were active contributor's to the OpenH323 project. We
> worked through several bugs, submitted patches and even sponsored
> development. We have also made contributions to other projects (some
> accepted, some not) on a much smaller scale over the years, QDox,
> Maruku, Capistrano, OpenGatekeeper, and Mono.
>
> === Homogeneous Developers ===
>
> Etch has been completely developed by Cisco employees, therefore all
> of the initial committers to the project are affiliated with Cisco.
>
> Etch has just recently been made publicly available. First in binary
> form in May 2008 as part of a Cisco product and in open source form in
> July 2008.
>
> === Reliance on Salaried Developers ===
>
> It is expected that Etch development will be done both on salaried
> time and volunteer time. Cisco is highly interested in the success and
> development of an Etch community. At this time, Etch is a core
> component of shipping Cisco products and is likely to grow over time.
> Cisco in interested in investing time to support Etch development and
> use it as a key component in multiple products. It is also expected
> that non-Cisco developers will become interested in Etch.
>
> === Relationships with Other Apache Products ===
>
> Etch currently depends upon these other Apache projects: Velocity,
> Maven and Ant.
>
> We expect that as Etch becomes available, it will be seen as a very
> compelling technology and others will begin to depend upon it.
>
> === A Excessive Fascination with the Apache Brand ===
>
> We believe Etch offers much to the Apache brand. We could easily, with
> the backing of Cisco, take a more independent route and support Etch
> directly without the Apache foundation. But after much consideration,
> we truly believe that would be the wrong approach for this technology.
>
> As a technology, we believe Etch is very much a kindred spirit of the
> other software infrastructure technologies currently part of the
> Apache community: Ant, Velocity, Derby, and others. The technological
> niche of Etch--platform and language agnostic service definition and
> binding-is a technology that can be appreciated across a broad range
> software domains.
>
> It is our view that Apache is simply the most appropriate community
> for the kind of technology Etch represents.
>
> == Documentation ==
>
> Public documents are available. All documentation can be found here
> http://developer.cisco.com/web/cuae/etch .
>
> == Initial Source ==
>
> Etch has been in development at Cisco since Jan-2007. The system was
> designed from the beginning to be open-sourced.  We consider Etch to
> be at release 1.0 and ready for production use.
>
> We continue to develop on Etch aggressively and a continually adding
> tests and documentation to accompany the code, in particular around
> Etch's unique pluggable architecture.
>
> The compiler and language bindings for Java and C# are working and
> functional. Etch will be included in shipping Cisco products in
> Sept-2008 as a core technology component.
>
> The language bindings for JavaScript, Python and C are in development.
> The Etch development home page is currently hosted a Cisco's developer
> portal: http://developer.cisco.com/web/cuae/etch . Full source and
> binary distributions are available there including access to our
> public subversion repository.
>
> == Source and Intellectual Property Submission Plan ==
>
> Apache would receive all source and documentation under the Apache
> Corporate Contributor agreement. Cisco is the only license holder.
>
> == External Dependencies ==
>
> Java, JavaCC and Velocity are core dependencies of the compiler. The
> Java language binding depends only on Java.
>
> Ant and Maven are used by the build system.
>
> For the other language bindings we have the following compile/link dependencies:
>
> C# - Microsoft .NET v2.0 (Mono compatibility coming soon)
>
> == Cryptography ==
>
> Etch uses the native capabilities of Java and C# to support TLS as an
> option for the default Etch binary transport protocol.
>
> == Required Resources ==
>
> === Mailing Lists ===
>
>  * etch-private
>  * etch-dev
>  * etch-commits
>  * etch-user
>
> === Subversion Directory ===
>
>  https://svn.apache.org/repos/asf/incubator/etch
>
> === Issue Tracking ===
>
>  JIRA : Etch (ETCH)
>
> === Other Resources ===
>
>  None
>
> == Initial Committers ==
>
>
> Gaurav Sandhir      gsandhir at cisco dot com
>
> J.D. Liau           jliau at cisco dot com
>
> James Dixson        jadixson at cisco dot com
>
> James deCocq      jadecocq at cisco dot com
>
> Rene Barazza        rebarraz at cisco dot com
>
> Scott Comer         sccomer at cisco dot com
>
> Seth Call           secall at cisco dot com
>
> Youngjin Park     youngjpa at cisco dot com
>
> === Affiliations ===
>
> All the initial committers are Cisco employees.
>
> == Sponsors ==
>
> === Champion ===
>
> Niclas Hedhman (has offered to be Champion)
>
> === Nominated Mentors ===
>
> Niclas Hedhman
>
> Doug Cutting
>
> Yonik Seeley
>
> === Sponsoring Entity ===
>
> Incubator
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

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

Re: [VOTE] accept Etch into the Incubator

[Yonik Seeley <yo...@apache.org>]

Since wiki pages can change, the full text of the proposal needs to be
in the vote thread.
Here is the text of the proposal:

== Abstract ==

Etch is a cross-platform, language- and transport-independent
framework for building and consuming network services.

== Proposal ==

Etch is a cross-platform, language- and transport-independent
framework for building and consuming network services. The Etch
toolset includes a network service description language, a compiler,
and binding libraries for a variety of programming languages. Etch is
also transport-independent, allowing for a variety of different
transports to used based on need and circumstance. The goal of Etch is
to make it simple to define small, focused services that can be easily
accessed, combined, and deployed in a similar manner. Ultimately with
Etch, service development and consumption becomes no more difficult
than library development and consumption.

== Background ==

Etch was started because we wanted to have a way to write a concise,
formal description of the message exchange between a client and a
server, with that message exchange supporting a hefty set of
requirements. The messaging technology should support one-way and
two-way, real-time communication. It should have high performance and
scalability. I should support clients and servers written in different
languages. It should also support clients/servers running in a wide
range of contexts (such as thin web client, embedded device, PC
application, or server). It must support anyone adding new language
bindings and new transports. It should also be fast and small, while
still being flexible enough to satisfy requirements. Finally, it must
be easy to use for developers both implementing and/or consuming the
service.

== Rationale ==

Existing systems were either too slow, hard to use, bloated and/or
proprietary. In any case, none fit our matrix of requirements
perfectly.

Developers of applications that must leverage the capabilities of
network-hosted services have a daunting challenge. They must cobble
together a heterogeneous collection of services that expose different
APIs with different communications technologies just to integrate with
the services, essentially spending a great deal of energy and effort
on just the basics of inter-service communication rather than core
business logic.

So the desired state then is when developing applications that
leverage the capabilities of dispersed and heterogeneous network
services, APIs must be simple, cohesive, and coherent across network
services. APIs should be easy to consume by developers regardless of
the implementation technology of the service used or the domain a
service is being built within- from client-side web applications to
complex real-time server systems. Put simply, developers ideally
should feel that they are developing to a platform.

API development is a much better understood and simpler subject if you
are building those APIs to be run _locally_ on a single machine or
service. Microsoft and Linux centric API developers have the luxury of
the massive assumption that a standard OS is available with a certain
set of features, and the API libraries do not have to take into
account the complexities of APIs that cross machine or OS boundaries.

Developers of network-centered services, rather than OS-centered
services, do not have this luxury; we have a significant set of issues
facing us today because of the fundamental fact that "the network" is
not a single machine, or a homogeneous set of machines, but a
heterogeneous and widely distributed set of services.

The conventional method for developers of network services today is to
use either a technology specific to the language of preference, RMI
for Java, .NET Remoting for .NET for C#, etc., or if trying to be
"language neutral" picking a CORBA ORB or a Web Service technology
like SOAP or REST. These choices are fine until the requirements of
the application cannot accept the limitations of the remoting
technology. If the application needs to work on non-Microsoft
platforms, .NET Remoting is out (unless, of course, you can use the
Mono implementation of .NET, but that brings with it other
challenges). If the need is to support access from languages other
than Java, then RMI is out. If the need includes support for
real-time, asynchronous communication, or symmetric two-way
communications, the Web services technologies must also be rejected.

For other classes of applications, there are simply no "standard"
choices left. The developer is forced to drop down to a network
protocol level and invent a new messaging system for their needs.
Building a protocol by hand is hard; building a messaging system is
also hard. This dramatically increases the barrier to entry for new,
useful applications that leverage network-services.

An orthogonal problem exists when supporting more than one transport
technology is required of the application, e.g. HTTP/SOAP and
HTTP/REST or HTTP/SOAP and a proprietary service protocol. This is
also burdensome to the developer because now two or more distinct
technologies must be used to expose the same interface. This typically
means the development and maintenance of parallel implementations of
the service using the technologies native to the transport mechanism.
Often the result here is that one interface is the complete interface,
while others suffer from various levels of partial or out-of-sync
implementation.

What if this was the reality instead: every interface to a network
service could be had via a single, common API technology that 'just
works' in every major language (C#, Java, Python, Ruby, C or even
Javascript in a browser). What if this technology could produce the
native stub code needed to do the networking and message passing (much
like Web Services). Then the developer could concentrate on the
business logic of the application or service rather than the
idiosyncrasies of the network plumbing.

As a language and transport independent network API generator, Etch
can provide programmers with a consistent API model to program against
while giving them the ability to redeploy into a variety of languages
or transports at runtime (per developer/customer choice). So, one may
use the same API implementation to send messages using an XML coding
on a stream protocol in Java, or binary coding wrapped in reliable UDP
in C#, or a shared memory queue on a router backplane in C, or even
Python over SOAP. One could, in fact, support all at the same time,
and any others that you care to implement or find, as long as you
support the required semantics of the API.

It all comes down to this: developers should not have to care about
the implementation language or platform of the service nor what the
transport is to get there, as long as basic semantics are honored, and
these should be no more or less than the semantics of your programming
language of choice. Further, a user requirement about specific
protocols should not require rewriting of application logic to make it
fit into some arbitrary framework scheme or container.

== Current Status ==

=== Meritocracy ===

Etch was conceived by Scott Comer and Louis Marascio. As Scott
finished the development of the core compiler and first transport
implementation, others have made various contributions to the project:
James Dixson and Shawn Dempsey have worked on the build environment;
Manoj Ganesan has worked on a Ruby binding; James Dixson on the Python
binding; and James deCocq on the C binding; Manoj Ganesan and Gaurav
Sandhir did primary work on C# and maintenance work all around. J.D.
Liau has been instrumental in ideas and maintenance. Hung Nguyen has
created the Windows installer using NSIS and Seth Call is working on a
JavaScript binding with JSON transport for thin clients.

=== Community ===

Etch solves problems lots of projects have. Any project that has a
need to define multiple services in a consistent way, or expose
services on the network to a variety of languages or platforms can
benefit from Etch as technology.

=== Core Developers ===


The core developers are all listed in the initial committers list
later in this proposal.

=== Alignment ===

The compiler code is in Java, but the technology is language- and
protocol-agnostic and suitable for many different projects, including
non-Java. The compiler makes use of Apache Ant for orchestrating the
build, and Apache Velocity for code generation.

== Known Risks ==

=== Orphaned Products ===

We are all quite committed to Etch and the development of an Etch
community. Etch is a core component of shipping Cisco products and
will only grow over time.

Our employer is also committed to the success of the technology,
allowing us to continue to invest our time in support of Etch
development as well as committing to Etch technology as a key
component in multiple products.

Etch being orphaned is unlikely.

=== Inexperience with Open Source ===

The group of initial committers has had various levels of interaction
with open-source communities. Most of us came into Cisco through the
acquisition of Metreos in 2006. While at Metreos, Louis Marascio and
several of us were active contributor's to the OpenH323 project. We
worked through several bugs, submitted patches and even sponsored
development. We have also made contributions to other projects (some
accepted, some not) on a much smaller scale over the years, QDox,
Maruku, Capistrano, OpenGatekeeper, and Mono.

=== Homogeneous Developers ===

Etch has been completely developed by Cisco employees, therefore all
of the initial committers to the project are affiliated with Cisco.

Etch has just recently been made publicly available. First in binary
form in May 2008 as part of a Cisco product and in open source form in
July 2008.

=== Reliance on Salaried Developers ===

It is expected that Etch development will be done both on salaried
time and volunteer time. Cisco is highly interested in the success and
development of an Etch community. At this time, Etch is a core
component of shipping Cisco products and is likely to grow over time.
Cisco in interested in investing time to support Etch development and
use it as a key component in multiple products. It is also expected
that non-Cisco developers will become interested in Etch.

=== Relationships with Other Apache Products ===

Etch currently depends upon these other Apache projects: Velocity,
Maven and Ant.

We expect that as Etch becomes available, it will be seen as a very
compelling technology and others will begin to depend upon it.

=== A Excessive Fascination with the Apache Brand ===

We believe Etch offers much to the Apache brand. We could easily, with
the backing of Cisco, take a more independent route and support Etch
directly without the Apache foundation. But after much consideration,
we truly believe that would be the wrong approach for this technology.

As a technology, we believe Etch is very much a kindred spirit of the
other software infrastructure technologies currently part of the
Apache community: Ant, Velocity, Derby, and others. The technological
niche of Etch--platform and language agnostic service definition and
binding-is a technology that can be appreciated across a broad range
software domains.

It is our view that Apache is simply the most appropriate community
for the kind of technology Etch represents.

== Documentation ==

Public documents are available. All documentation can be found here
http://developer.cisco.com/web/cuae/etch .

== Initial Source ==

Etch has been in development at Cisco since Jan-2007. The system was
designed from the beginning to be open-sourced.  We consider Etch to
be at release 1.0 and ready for production use.

We continue to develop on Etch aggressively and a continually adding
tests and documentation to accompany the code, in particular around
Etch's unique pluggable architecture.

The compiler and language bindings for Java and C# are working and
functional. Etch will be included in shipping Cisco products in
Sept-2008 as a core technology component.

The language bindings for JavaScript, Python and C are in development.
The Etch development home page is currently hosted a Cisco's developer
portal: http://developer.cisco.com/web/cuae/etch . Full source and
binary distributions are available there including access to our
public subversion repository.

== Source and Intellectual Property Submission Plan ==

Apache would receive all source and documentation under the Apache
Corporate Contributor agreement. Cisco is the only license holder.

== External Dependencies ==

Java, JavaCC and Velocity are core dependencies of the compiler. The
Java language binding depends only on Java.

Ant and Maven are used by the build system.

For the other language bindings we have the following compile/link dependencies:

C# - Microsoft .NET v2.0 (Mono compatibility coming soon)

== Cryptography ==

Etch uses the native capabilities of Java and C# to support TLS as an
option for the default Etch binary transport protocol.

== Required Resources ==

=== Mailing Lists ===

 * etch-private
 * etch-dev
 * etch-commits
 * etch-user

=== Subversion Directory ===

 https://svn.apache.org/repos/asf/incubator/etch

=== Issue Tracking ===

 JIRA : Etch (ETCH)

=== Other Resources ===

 None

== Initial Committers ==


Gaurav Sandhir      gsandhir at cisco dot com

J.D. Liau           jliau at cisco dot com

James Dixson        jadixson at cisco dot com

James deCocq      jadecocq at cisco dot com

Rene Barazza        rebarraz at cisco dot com

Scott Comer         sccomer at cisco dot com

Seth Call           secall at cisco dot com

Youngjin Park     youngjpa at cisco dot com

=== Affiliations ===

All the initial committers are Cisco employees.

== Sponsors ==

=== Champion ===

Niclas Hedhman (has offered to be Champion)

=== Nominated Mentors ===

Niclas Hedhman

Doug Cutting

Yonik Seeley

=== Sponsoring Entity ===

Incubator

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

Re: [VOTE] accept Etch into the Incubator

[Matt Hogstrom <ma...@hogstrom.org>]

+1 (binding)

On Aug 25, 2008, at 1:22 PM, James Dixson wrote:

> Please vote on accepting Etch into the Incubator.
>
> The Etch proposal is at:
>
>   http://wiki.apache.org/incubator/EtchProposal
>
>
> -- 
> James
>
>
>
> ---------------------------------------------------------------------
> 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

Re: [VOTE] accept Etch into the Incubator

["Alan D. Cabrera" <li...@toolazydogs.com>]

+1 (binding)

On Aug 25, 2008, at 10:22 AM, James Dixson wrote:

> Please vote on accepting Etch into the Incubator.
>
> The Etch proposal is at:
>
>   http://wiki.apache.org/incubator/EtchProposal
>
>
> -- 
> James
>
>
>
> ---------------------------------------------------------------------
> 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

Re: [VOTE] accept Etch into the Incubator

[Niklas Gustavsson <ni...@protocol7.com>]

On Mon, Aug 25, 2008 at 7:22 PM, James Dixson <ja...@cisco.com> wrote:
> Please vote on accepting Etch into the Incubator.

+1 (non-binding)

/niklas

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