You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by James Dixson <ja...@cisco.com> on 2008/07/31 18:16:57 UTC
[PROPOSAL] Etch
This a proposal to enter Etch in to the incubator.
See http://wiki.apache.org/incubator/EtchProposal for updates.
In particular, we are looking for an interested Champion.
We welcome any and all comments. :-)
--
James Dixson
-----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.
SOAP/Web Services offer an interesting comparison by contrast. While Web
Services are generally accepted as the de facto standard for cross-platform
communication due to strong adoption across many tools and languages, the
unfortunate reality is that Web Services have serious deficiencies which
make them unsuitable for real-time communications. Specifically, Web
Services have no effective way to communicate asynchronously from server to
client due to a reliance on HTTP and have very high parsing overhead due to
XML message bodies. Furthermore, in some deployments, server-to-client
communications are blocked by firewalls. Finally, given any two languages,
it is not likely that they both support every aspect of Web Services
identically, so it is completely possible to create a Web Service that is
not, in fact, cross platform, or language agnostic.
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.( This is just an observation. 4 paragraphs to make your
point about how difficult it is for developers of network-centered service.
Now, maybe that is appropriate to the audience? You decide.)
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 committed as a corporate contributor to continue to
allow Etch development, particularly in light of Etch's key role as an
enabling technology of Unified Communications 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
No public documents are available yet. All documentation will be released
with the publishing of the source.
= 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
Hung Nguyen hungng at cisco dot com
James Dixson jadixson at cisco dot com
James deCocq jadecocq at cisco dot com
Louis Marascio lmarasci at cisco dot com
Manoj Ganesan manogane at cisco dot com
Rene Barazza rebarraz at cisco dot com
Rick Bolkey rbolkey at cisco dot com
Scott Comer sccomer at cisco dot com
Seth Call secall at cisco dot com
Shawn Dempsay shawn at dempsay dot com
Shyamali Pease shpease at cisco dot com
Youngjin Park youngjpa at cisco dot com
== Affiliations
All the initial committers are Cisco employees.
= Sponsors
== Champion
We need a hero!
== Nominated Mentors
Accepting Applications!
== Sponsoring Entity
Accepting Applications!
--
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by "scott comer (sccomer)" <sc...@cisco.com>.
thrift had a number of issues as we considered it more than a year ago. we thought, well, we could fix these issues, but as they'd require interface changes then we'd be breaking someone else's code and the fixes would be substantial and then we'd have to negotiate each and every one of them, blah, blah. in the end, it was all too much.
i actually had a fully functional basic etch framework put together (hand built code) when i first checked out thrift (eh, march 2007?). etch was was good enough to be able to compare the two. the comparison was favorable enough to our path (i.e., near parity in performance, way better features) we decided to continue our path rather than suffer thrift negatives.
1) the thrift language is not pretty (i16 instead of short, weird numbering of parameters).
2) thrift compiler is written in c. not easy to bring up.
3) no c# binding.
4) while there is some transport independence, the transport is chosen at compile time. there is no runtime choice for the customer.
5) generated code is not truly transport independent. (e.g., you could not write a generic soap <-> thrift gateway). generated code deals with stream semantics directly, not an abstract idea of message which gives etch a lot of its power and simplicity.
6) the type system doesn't always allow for optional arguments (integer value cannot be passed as null).
7) thrift is not thread safe (or it didn't appear so to me).
8) no extends of structures and exceptions.
9) thrift exceptions are strange.
10) no callbacks.
11) no timeouts.
12) no constants.
13) no object.
14) no enums.
15) no formal comments.
16) no mixin or include.
17) no module.
18) overall interface and implementation flavor is of c++ code ported to java.
thrift does not version services (not in the corba sense). etch doesn't either. they are both alike in that respect.
a common approach to versioning is that you generate a signature for each method or the entire service, and two endpoints will only talk to each other if the signature matches (either method by method or the entire service). this is wrong at either level, as it means you have no upgrade path which doesn't require complete and perfect redeployment of all clients. corba and onc/rpc and dce/rpc fall into this category (as well as languages like c/c++/java/c#). i don't think that soap / web services / xml rpc fall into this model, either.
the thrift/etch/xml model, ignoring small details, are like the original rpc model that cuae was based on: code your method call into what is (more or less) a hashtable, with field/value pairs and then a type code (for the operation). then move that over the transport. the receiver picks and chooses what it wants out of the hashtable. if you send a message type the recipient doesn't expect, he ignores it. if you send a field the recipient doesn't expect, he ignores it. if you don't send a field the recipient expects, he can 1) complain, 2) pass on the fact that it was missing, 3) set it to a default value, 4) crash.
thrift does both 2 and 3. passes a default value and also marks it as not being set. smart code must check for the presence of a parameter before assuming it is there.
etch does 2, by using reference parameters for native types (such as Integer for int in java, int? for int in csharp), which makes it both simpler and clearer, and more robust. this comes with no particular penalty for most of the interesting languages (java, c#, ruby, python, php, javascript, cuae). the only binding that suffers is c/c++, which is already suffering plenty for other reasons (threads, storage management, type systems).
scott out
Yonik Seeley wrote:
> On Thu, Jul 31, 2008 at 12:16 PM, James Dixson <ja...@cisco.com> wrote:
>
>> This a proposal to enter Etch in to the incubator.
>>
>
> James, could you perhaps describe how this differs from Thrift?
>
> -Yonik
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [PROPOSAL] Etch
Posted by Yonik Seeley <yo...@apache.org>.
On Thu, Jul 31, 2008 at 12:16 PM, James Dixson <ja...@cisco.com> wrote:
> This a proposal to enter Etch in to the incubator.
James, could you perhaps describe how this differs from Thrift?
-Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by Paul Fremantle <pz...@gmail.com>.
Yes that was the paragraph I was referring to.
Paul
On Fri, Aug 1, 2008 at 9:29 PM, James Dixson <ja...@cisco.com> wrote:
> Paul,
>
> Are you referring to the "SOAP/Web Services offer an interesting comparison
> ..." paragraph?
>
> If so, then I agree it is probably redundant to the Etch rationale and I can
> remove it.
>
> --
> james
>
> On 8/1/08 12:34 PM, "Paul Fremantle" <pz...@gmail.com> wrote:
>
>> James
>>
>> I know its popular to bash SOAP at this point, but there are simple
>> factual inaccuracies in your "why not SOAP" section. Rather than argue
>> about the details I'd like to point out that this section is
>> redundant. Do you really feel you need this in there? If you do I'll
>> start listing your inaccuracies.
>>
>> Paul
>>
>> On Thu, Jul 31, 2008 at 5:16 PM, James Dixson <ja...@cisco.com> wrote:
>>> This a proposal to enter Etch in to the incubator.
>>>
>>> See http://wiki.apache.org/incubator/EtchProposal for updates.
>>>
>>> In particular, we are looking for an interested Champion.
>>>
>>> We welcome any and all comments. :-)
>>>
>>>
>>> --
>>> James Dixson
>>>
>>>
>>> -----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.
>>>
>>> SOAP/Web Services offer an interesting comparison by contrast. While Web
>>> Services are generally accepted as the de facto standard for cross-platform
>>> communication due to strong adoption across many tools and languages, the
>>> unfortunate reality is that Web Services have serious deficiencies which
>>> make them unsuitable for real-time communications. Specifically, Web
>>> Services have no effective way to communicate asynchronously from server to
>>> client due to a reliance on HTTP and have very high parsing overhead due to
>>> XML message bodies. Furthermore, in some deployments, server-to-client
>>> communications are blocked by firewalls. Finally, given any two languages,
>>> it is not likely that they both support every aspect of Web Services
>>> identically, so it is completely possible to create a Web Service that is
>>> not, in fact, cross platform, or language agnostic.
>>>
>>> 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.( This is just an observation. 4 paragraphs to make your
>>> point about how difficult it is for developers of network-centered service.
>>> Now, maybe that is appropriate to the audience? You decide.)
>>>
>>> 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 committed as a corporate contributor to continue to
>>> allow Etch development, particularly in light of Etch's key role as an
>>> enabling technology of Unified Communications 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
>>>
>>> No public documents are available yet. All documentation will be released
>>> with the publishing of the source.
>>>
>>> = 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
>>> Hung Nguyen hungng at cisco dot com
>>> James Dixson jadixson at cisco dot com
>>> James deCocq jadecocq at cisco dot com
>>> Louis Marascio lmarasci at cisco dot com
>>> Manoj Ganesan manogane at cisco dot com
>>> Rene Barazza rebarraz at cisco dot com
>>> Rick Bolkey rbolkey at cisco dot com
>>> Scott Comer sccomer at cisco dot com
>>> Seth Call secall at cisco dot com
>>> Shawn Dempsay shawn at dempsay dot com
>>> Shyamali Pease shpease at cisco dot com
>>> Youngjin Park youngjpa at cisco dot com
>>>
>>> == Affiliations
>>>
>>> All the initial committers are Cisco employees.
>>>
>>> = Sponsors
>>>
>>> == Champion
>>>
>>> We need a hero!
>>>
>>> == Nominated Mentors
>>>
>>> Accepting Applications!
>>>
>>> == Sponsoring Entity
>>>
>>> Accepting Applications!
>>>
>>> --
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>
>>
>
> --
> James Dixson
> Manager, Software Development
> CUAE Engineering, Cisco Systems
> (e) jadixson@cisco.com
> (p) 512-336-3305
> (m) 512-968-2116
>
>
>
> ---------------------------------------------------------------------
> 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: [PROPOSAL] Etch
Posted by James Dixson <ja...@cisco.com>.
Paul,
Are you referring to the "SOAP/Web Services offer an interesting comparison
..." paragraph?
If so, then I agree it is probably redundant to the Etch rationale and I can
remove it.
--
james
On 8/1/08 12:34 PM, "Paul Fremantle" <pz...@gmail.com> wrote:
> James
>
> I know its popular to bash SOAP at this point, but there are simple
> factual inaccuracies in your "why not SOAP" section. Rather than argue
> about the details I'd like to point out that this section is
> redundant. Do you really feel you need this in there? If you do I'll
> start listing your inaccuracies.
>
> Paul
>
> On Thu, Jul 31, 2008 at 5:16 PM, James Dixson <ja...@cisco.com> wrote:
>> This a proposal to enter Etch in to the incubator.
>>
>> See http://wiki.apache.org/incubator/EtchProposal for updates.
>>
>> In particular, we are looking for an interested Champion.
>>
>> We welcome any and all comments. :-)
>>
>>
>> --
>> James Dixson
>>
>>
>> -----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.
>>
>> SOAP/Web Services offer an interesting comparison by contrast. While Web
>> Services are generally accepted as the de facto standard for cross-platform
>> communication due to strong adoption across many tools and languages, the
>> unfortunate reality is that Web Services have serious deficiencies which
>> make them unsuitable for real-time communications. Specifically, Web
>> Services have no effective way to communicate asynchronously from server to
>> client due to a reliance on HTTP and have very high parsing overhead due to
>> XML message bodies. Furthermore, in some deployments, server-to-client
>> communications are blocked by firewalls. Finally, given any two languages,
>> it is not likely that they both support every aspect of Web Services
>> identically, so it is completely possible to create a Web Service that is
>> not, in fact, cross platform, or language agnostic.
>>
>> 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.( This is just an observation. 4 paragraphs to make your
>> point about how difficult it is for developers of network-centered service.
>> Now, maybe that is appropriate to the audience? You decide.)
>>
>> 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 committed as a corporate contributor to continue to
>> allow Etch development, particularly in light of Etch's key role as an
>> enabling technology of Unified Communications 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
>>
>> No public documents are available yet. All documentation will be released
>> with the publishing of the source.
>>
>> = 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
>> Hung Nguyen hungng at cisco dot com
>> James Dixson jadixson at cisco dot com
>> James deCocq jadecocq at cisco dot com
>> Louis Marascio lmarasci at cisco dot com
>> Manoj Ganesan manogane at cisco dot com
>> Rene Barazza rebarraz at cisco dot com
>> Rick Bolkey rbolkey at cisco dot com
>> Scott Comer sccomer at cisco dot com
>> Seth Call secall at cisco dot com
>> Shawn Dempsay shawn at dempsay dot com
>> Shyamali Pease shpease at cisco dot com
>> Youngjin Park youngjpa at cisco dot com
>>
>> == Affiliations
>>
>> All the initial committers are Cisco employees.
>>
>> = Sponsors
>>
>> == Champion
>>
>> We need a hero!
>>
>> == Nominated Mentors
>>
>> Accepting Applications!
>>
>> == Sponsoring Entity
>>
>> Accepting Applications!
>>
>> --
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
--
James Dixson
Manager, Software Development
CUAE Engineering, Cisco Systems
(e) jadixson@cisco.com
(p) 512-336-3305
(m) 512-968-2116
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by Paul Fremantle <pz...@gmail.com>.
James
I know its popular to bash SOAP at this point, but there are simple
factual inaccuracies in your "why not SOAP" section. Rather than argue
about the details I'd like to point out that this section is
redundant. Do you really feel you need this in there? If you do I'll
start listing your inaccuracies.
Paul
On Thu, Jul 31, 2008 at 5:16 PM, James Dixson <ja...@cisco.com> wrote:
> This a proposal to enter Etch in to the incubator.
>
> See http://wiki.apache.org/incubator/EtchProposal for updates.
>
> In particular, we are looking for an interested Champion.
>
> We welcome any and all comments. :-)
>
>
> --
> James Dixson
>
>
> -----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.
>
> SOAP/Web Services offer an interesting comparison by contrast. While Web
> Services are generally accepted as the de facto standard for cross-platform
> communication due to strong adoption across many tools and languages, the
> unfortunate reality is that Web Services have serious deficiencies which
> make them unsuitable for real-time communications. Specifically, Web
> Services have no effective way to communicate asynchronously from server to
> client due to a reliance on HTTP and have very high parsing overhead due to
> XML message bodies. Furthermore, in some deployments, server-to-client
> communications are blocked by firewalls. Finally, given any two languages,
> it is not likely that they both support every aspect of Web Services
> identically, so it is completely possible to create a Web Service that is
> not, in fact, cross platform, or language agnostic.
>
> 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.( This is just an observation. 4 paragraphs to make your
> point about how difficult it is for developers of network-centered service.
> Now, maybe that is appropriate to the audience? You decide.)
>
> 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 committed as a corporate contributor to continue to
> allow Etch development, particularly in light of Etch's key role as an
> enabling technology of Unified Communications 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
>
> No public documents are available yet. All documentation will be released
> with the publishing of the source.
>
> = 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
> Hung Nguyen hungng at cisco dot com
> James Dixson jadixson at cisco dot com
> James deCocq jadecocq at cisco dot com
> Louis Marascio lmarasci at cisco dot com
> Manoj Ganesan manogane at cisco dot com
> Rene Barazza rebarraz at cisco dot com
> Rick Bolkey rbolkey at cisco dot com
> Scott Comer sccomer at cisco dot com
> Seth Call secall at cisco dot com
> Shawn Dempsay shawn at dempsay dot com
> Shyamali Pease shpease at cisco dot com
> Youngjin Park youngjpa at cisco dot com
>
> == Affiliations
>
> All the initial committers are Cisco employees.
>
> = Sponsors
>
> == Champion
>
> We need a hero!
>
> == Nominated Mentors
>
> Accepting Applications!
>
> == Sponsoring Entity
>
> Accepting Applications!
>
> --
>
>
> ---------------------------------------------------------------------
> 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: [PROPOSAL] Etch
Posted by Doug Cutting <cu...@apache.org>.
James Dixson wrote:
> This a proposal to enter Etch in to the incubator.
+1 for incubation.
I will gladly be a mentor.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 07 August 2008 12:16:47 Yonik Seeley wrote:
> And I also qualify on that point.
Then I am so sorry. As Bill pointed out, it ain't easy to recall exactly who
are Members and who are not...
I will adjust the Proposal.
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 07 August 2008 14:33:57 Paul Fremantle wrote:
> Niclas
>
> I offered as a backup. I'm perfectly happy for the proposal to go
> forwards with the three original mentors. I will probably join the
> mailing lists anyway.
Ok, noted in proposal.
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by Paul Fremantle <pz...@gmail.com>.
Niclas
I offered as a backup. I'm perfectly happy for the proposal to go
forwards with the three original mentors. I will probably join the
mailing lists anyway.
Thanks!
Paul
On Thu, Aug 7, 2008 at 6:35 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Thursday 07 August 2008 12:16:47 Yonik Seeley wrote:
>> And I also qualify on that point.
>
> Then I am so sorry. As Bill pointed out, it ain't easy to recall exactly who
> are Members and who are not...
>
> I will adjust the Proposal.
>
> Paul, do you still want to be Mentor??
>
>
> Cheers
> --
> Niclas Hedhman, Software Developer
>
> I live here; http://tinyurl.com/2qq9er
> I work here; http://tinyurl.com/2ymelc
> I relax here; http://tinyurl.com/2cgsug
>
> ---------------------------------------------------------------------
> 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: [PROPOSAL] Etch
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 07 August 2008 12:16:47 Yonik Seeley wrote:
> And I also qualify on that point.
Then I am so sorry. As Bill pointed out, it ain't easy to recall exactly who
are Members and who are not...
I will adjust the Proposal.
Paul, do you still want to be Mentor??
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Yonik Seeley wrote:
> On Thu, Aug 7, 2008 at 12:10 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
>> On Thursday 07 August 2008 10:50:10 Yonik Seeley wrote:
>>
>>> "The Sponsor shall assign a Mentor, who shall be granted membership of
>>> the Incubator PMC for the duration of the incubation process."
>>> That's also why they are listed as Nominated Members... the Incubator
>>> PMC must confirm them.
>> Yes, but there is a constraint on who can become Incubator PMC member, namely;
>> ASF Members.
>
> And I also qualify on that point.
Right you are (with 240-some members, it can become confusing). Simply
email private@incubator with your request to become a PMC member, and Noel
will relay this to the board.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by Yonik Seeley <yo...@apache.org>.
On Thu, Aug 7, 2008 at 12:10 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Thursday 07 August 2008 10:50:10 Yonik Seeley wrote:
>
>> "The Sponsor shall assign a Mentor, who shall be granted membership of
>> the Incubator PMC for the duration of the incubation process."
>> That's also why they are listed as Nominated Members... the Incubator
>> PMC must confirm them.
>
> Yes, but there is a constraint on who can become Incubator PMC member, namely;
> ASF Members.
And I also qualify on that point.
-Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 07 August 2008 10:50:10 Yonik Seeley wrote:
> "The Sponsor shall assign a Mentor, who shall be granted membership of
> the Incubator PMC for the duration of the incubation process."
> That's also why they are listed as Nominated Members... the Incubator
> PMC must confirm them.
Yes, but there is a constraint on who can become Incubator PMC member, namely;
ASF Members. There are also a handful of rare cases where the PMC vote in
non-Members on merit, but that is quite exceptional.
I thought we have revised the cited paragraph to be more clear.
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by Yonik Seeley <yo...@apache.org>.
On Wed, Aug 6, 2008 at 10:20 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
> Now;
> Niclas Hedhman
> Doug Cutting
> Paul Fremantle
>
> I had to remove Yonik from the list of formal Mentors, as he is not on the
> Incubator PMC (AFAICT).
Huh? Mentors become part of the Incubator PMC.
"The Sponsor shall assign a Mentor, who shall be granted membership of
the Incubator PMC for the duration of the incubation process."
That's also why they are listed as Nominated Members... the Incubator
PMC must confirm them.
-Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 01 August 2008 00:16:57 James Dixson wrote:
> == Nominated Mentors
Now;
Niclas Hedhman
Doug Cutting
Paul Fremantle
I had to remove Yonik from the list of formal Mentors, as he is not on the
Incubator PMC (AFAICT). Paul Fremantle has volunteered, so I put him up as
well.
All experienced hands are of course welcomed, even if it is not formalized
people who have been through incubation is a very good resource to have
around podlings, so Yonik, don't feel discouraged... ;o)
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by James Dixson <ja...@cisco.com>.
Thank you for the support Yonik!
--
james
On 8/4/08 3:00 PM, "Yonik Seeley" <yo...@apache.org> wrote:
> I've spent some time looking at the existing documentation, and
> checking out the video introduction.... great stuff! I think it could
> fit well in the ASF, and I have a personal interest in perhaps using
> it for Solr 2.0.
>
> I'll certainly volunteer to be a Mentor.
>
> -Yonik
>
> On Thu, Jul 31, 2008 at 12:16 PM, James Dixson <ja...@cisco.com> wrote:
>> This a proposal to enter Etch in to the incubator.
>>
>> See http://wiki.apache.org/incubator/EtchProposal for updates.
>>
>> In particular, we are looking for an interested Champion.
>>
>> We welcome any and all comments. :-)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
--
James Dixson
Manager, Software Development
CUAE Engineering, Cisco Systems
(e) jadixson@cisco.com
(p) 512-336-3305
(m) 512-968-2116
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by Yonik Seeley <yo...@apache.org>.
I've spent some time looking at the existing documentation, and
checking out the video introduction.... great stuff! I think it could
fit well in the ASF, and I have a personal interest in perhaps using
it for Solr 2.0.
I'll certainly volunteer to be a Mentor.
-Yonik
On Thu, Jul 31, 2008 at 12:16 PM, James Dixson <ja...@cisco.com> wrote:
> This a proposal to enter Etch in to the incubator.
>
> See http://wiki.apache.org/incubator/EtchProposal for updates.
>
> In particular, we are looking for an interested Champion.
>
> We welcome any and all comments. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by Craig L Russell <Cr...@Sun.COM>.
A modern replacement for CORBA? Just resist the temptation to
implement Persistence Services on top. ;-)
+1
Craig
On Jul 31, 2008, at 9:16 AM, James Dixson wrote:
> This a proposal to enter Etch in to the incubator.
>
> See http://wiki.apache.org/incubator/EtchProposal for updates.
>
> In particular, we are looking for an interested Champion.
>
> We welcome any and all comments. :-)
>
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: [PROPOSAL] Etch
Posted by Yonik Seeley <yo...@apache.org>.
On Fri, Aug 1, 2008 at 2:23 PM, scott comer (sccomer) <sc...@cisco.com> wrote:
> we might have overdone the committer list here a bit so nobody who made a
> significant contribution felt left out. :-)
Perhaps something like a FAQ entry "What is the history of Etch?" on
the web site would be a more appropriate way to recognize these?
-Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by Yonik Seeley <yo...@apache.org>.
+1
-Yonik
On Sat, Aug 9, 2008 at 4:58 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> On Fri, Aug 1, 2008 at 8:23 PM, scott comer (sccomer) <sc...@cisco.com> wrote:
>> we might have overdone the committer list here a bit so nobody who made a
>> significant contribution felt left out. :-)...
>
>> ...summary:
>>
>> architecture: scott comer
>> compiler, java and csharp binding: scott comer, gaurav sandhir
>> build: james dixson
>> c binding: james deCocq, rene barazza, youngjin park
>> javascript binding: seth call
>> python binding: james dixson
>> documentation: shy pease...
>
> That's 8 people, as opposed to 14 listed on the proposal.
>
> How about trimming the list to those 8 to start with?
>
> Others can gain committership along the way if they are active - but
> starting with 14 people form the same organization sounds like a high
> hurdle to jump in terms of community diversity.
>
> -Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Aug 1, 2008 at 8:23 PM, scott comer (sccomer) <sc...@cisco.com> wrote:
> we might have overdone the committer list here a bit so nobody who made a
> significant contribution felt left out. :-)...
> ...summary:
>
> architecture: scott comer
> compiler, java and csharp binding: scott comer, gaurav sandhir
> build: james dixson
> c binding: james deCocq, rene barazza, youngjin park
> javascript binding: seth call
> python binding: james dixson
> documentation: shy pease...
That's 8 people, as opposed to 14 listed on the proposal.
How about trimming the list to those 8 to start with?
Others can gain committership along the way if they are active - but
starting with 14 people form the same organization sounds like a high
hurdle to jump in terms of community diversity.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 8/1/08, scott comer (sccomer) <sc...@cisco.com> wrote:
> we might have overdone the committer list here a bit so nobody who made
> a significant contribution felt left out. :-)
Having a long committer list is not necessarily bad but projects which
enter with a long list of which only a small number are enthusiastic
and active often find incubation more challenging. For example,
listing someone as a committer means they need to fill in the
paperwork etc and subscribe to the lists. If people have made
significant contributions and are enthusiastic then they will be an
asset. If they aren't interested they the extra names may prove a
burden.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by "scott comer (sccomer)" <sc...@cisco.com>.
we might have overdone the committer list here a bit so nobody who made
a significant contribution felt left out. :-)
(in addition to what james dixson has reported about himself) for the
last two months, the main contributors to the compiler and the java and
csharp bindings (the core) have been gaurav and me. going forward,
support and enhancements to the core would fall mainly on gaurav and me.
manoj ganesan has spent a lot of time working on the core in the past,
and is currently supporting the xml binding and the cuae use of same.
for the last 9 months james deCocq has been working on the c binding.
rene barazza and youngjin park will be contributing to the c binding as
well. seth call has been working on the javascript binding / json
transport. generally patches to the core would be vetted by gaurav and
me, as well as recruiting and mentoring new contributors to the project.
summary:
architecture: scott comer
compiler, java and csharp binding: scott comer, gaurav sandhir
build: james dixson
c binding: james deCocq, rene barazza, youngjin park
javascript binding: seth call
python binding: james dixson
documentation: shy pease
of those, only gaurav and i are full time on the etch project, everyone
else has other duties as well. there is plenty of room for more
contributors on current and future projects:
ruby binding
python binding
web services gateway
web services transport
maven build
automated interop test framework and suite
better testing framework for the compiler
a host of smaller projects
scott out
James Dixson wrote:
> Well, personally I have been heavily involved in or have written outright
> the build system, compiler interface, and ant plug-in. I am currently
> working on a maven mojo and as well as a python binding that has full parity
> with the Java and C# bindings. I am a Manager at Cisco, but I am Developer
> with Etch.
>
> When we were discussing amongst ourselves who to include in the proposal, we
> tried to apply the same criteria regarding merit that we would need to apply
> if we were already an apache project.
>
> All of the folks on the list are folks that have been consistently active in
> Etch development over the last several months, myself included. It does not
> by any means include everyone who has ever touched Etch.
>
> The only small exception to that is Shawn, who was a contributor up until
> July of this year when he actually left Cisco. He still has merit with the
> team, but has not made any contributions to the codebase since leaving. This
> is not for a lack of interest, as the code base has only just recently been
> released as open source. :-)
>
> Btw .. I just realized I had shawn's new email in the proposal but not the
> fact he was no longer with Cisco... I corrected the proposal.
>
> --
> james
>
> On 8/1/08 9:57 AM, "Yonik Seeley" <yo...@apache.org> wrote:
>
>
>> On Fri, Aug 1, 2008 at 5:41 AM, Upayavira <uv...@odoko.co.uk> wrote:
>>
>>> 14 people from one organisation on the initial committer list looks to
>>> me like a daunting incubation.
>>>
>> Indeed. Which of those people will actually be working on Etch going forward?
>> A quick perusal shows a Manager and a Director of Engineering on that list.
>>
>> -Yonik
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
Re: [PROPOSAL] Etch
Posted by Mike Edwards <mi...@gmail.com>.
Henning,
I'd be grateful if you could explain this further.
When I look at the Etch proposal page, it does not seem that Etch is simply about a wire format, so
I am puzzled by your reply. There are some things I'm clearly not getting about Etch.
Yours, Mike.
Henning Schmiedehausen wrote:
> From my understanding, Tuscany could leverage Etch to offer a wire
> format that can be consumed by a variety of different languages and
> environments, not a contestant to it.
>
> Ciao
> Henning
>
>
>
> Mike Edwards schrieb:
>> Folks,
>>
>> Can I ask if anyone has compared Etch with Apache Tuscany and the SCA
>> specifications?
>>
>>
>> Yours, Mike.
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by Henning Schmiedehausen <he...@apache.org>.
From my understanding, Tuscany could leverage Etch to offer a wire
format that can be consumed by a variety of different languages and
environments, not a contestant to it.
Ciao
Henning
Mike Edwards schrieb:
> Folks,
>
> Can I ask if anyone has compared Etch with Apache Tuscany and the SCA
> specifications?
>
>
> Yours, Mike.
>
> ---------------------------------------------------------------------
> 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: [PROPOSAL] Etch
Posted by Mike Edwards <mi...@gmail.com>.
Folks,
Can I ask if anyone has compared Etch with Apache Tuscany and the SCA specifications?
Yours, Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by James Dixson <ja...@cisco.com>.
Well, personally I have been heavily involved in or have written outright
the build system, compiler interface, and ant plug-in. I am currently
working on a maven mojo and as well as a python binding that has full parity
with the Java and C# bindings. I am a Manager at Cisco, but I am Developer
with Etch.
When we were discussing amongst ourselves who to include in the proposal, we
tried to apply the same criteria regarding merit that we would need to apply
if we were already an apache project.
All of the folks on the list are folks that have been consistently active in
Etch development over the last several months, myself included. It does not
by any means include everyone who has ever touched Etch.
The only small exception to that is Shawn, who was a contributor up until
July of this year when he actually left Cisco. He still has merit with the
team, but has not made any contributions to the codebase since leaving. This
is not for a lack of interest, as the code base has only just recently been
released as open source. :-)
Btw .. I just realized I had shawn's new email in the proposal but not the
fact he was no longer with Cisco... I corrected the proposal.
--
james
On 8/1/08 9:57 AM, "Yonik Seeley" <yo...@apache.org> wrote:
> On Fri, Aug 1, 2008 at 5:41 AM, Upayavira <uv...@odoko.co.uk> wrote:
>> 14 people from one organisation on the initial committer list looks to
>> me like a daunting incubation.
>
> Indeed. Which of those people will actually be working on Etch going forward?
> A quick perusal shows a Manager and a Director of Engineering on that list.
>
> -Yonik
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
--
James Dixson
Manager, Software Development
CUAE Engineering, Cisco Systems
(e) jadixson@cisco.com
(p) 512-336-3305
(m) 512-968-2116
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by Yonik Seeley <yo...@apache.org>.
On Fri, Aug 1, 2008 at 5:41 AM, Upayavira <uv...@odoko.co.uk> wrote:
> 14 people from one organisation on the initial committer list looks to
> me like a daunting incubation.
Indeed. Which of those people will actually be working on Etch going forward?
A quick perusal shows a Manager and a Director of Engineering on that list.
-Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by Upayavira <uv...@odoko.co.uk>.
14 people from one organisation on the initial committer list looks to
me like a daunting incubation. To get some level of independence from
Cisco, that will mean recruiting at least 14 new committers. That is a
major task.
I see Shindig having the same issue - it is moving fast, and developing
well, but still with a strong Google contingent, and it will take quite
some time before that changes significantly.
So, with 14 initial committers from one org, I'd expect incubation to be
very slow.
Upayavira
On Fri, 2008-08-01 at 11:29 +0200, Henning Schmiedehausen wrote:
> You adressed the two concerns that I have, too, thanks.
>
> - The name. "Debian Etch" is a deeply engrained meme with the "Etch"
> short cut.
>
> - Office disussions. Projects where a large number of committers are
> from the same organization and that also have this company being
> invested in the project might fall into the "watercooler discussion"
> trap. Or into the "this is a patch for <foo>, I discussed and reviewed
> it with <few other committers> and they think it is fine" problem, where
> the review and discussion happened off the mailing list.
>
> It is definitely painful if you have the large majority of committers
> and contributors in the office to still send out stuff to the mailing
> lists, wait for people in other time zones to catch up and then go
> ahead. In fast moving projects (I'm talking about you, Shindig
> people. ;-) ), the aspect of a global distributed community sometimes
> gets forgotten if you have all the relevant people in the next room. So
> this is something that should be watched during incubation.
>
> Apart from that: Wow, cool product. +1 for incubation.
>
> Ciao
> Henning
>
>
> On Fri, 2008-08-01 at 11:28 +0800, Niclas Hedhman wrote:
> > On Friday 01 August 2008 00:16, James Dixson wrote:
> > > This a proposal to enter Etch in to the incubator.
> > >
> > > See http://wiki.apache.org/incubator/EtchProposal for updates.
> > >
> > > In particular, we are looking for an interested Champion.
> >
> > Well, you are expected to have found a Champion prior to submitting the
> > proposal, but that is not a blocker.
> >
> > "Etch" --> Not so sure. "Debian Etch vs Apache Etch, which one is better?"
> > Doh... I would seek another name.
> >
> > I like this proposal a lot, probably because of too many fingers burned on
> > SOAP. The challenge will be community building, and I have two fears;
> > 1. Codebase might be "too good".
> > 2. "At office" discussions on progress.
> >
> > Well, I am willing to be a Mentor on this podling if accepted. List me as
> > Champion if you don't get anyone else. And you are effectively requesting the
> > Incubator PMC to be the Sponsor.
> >
> >
> > My +1 for Incubation.
> >
> >
> > Cheers
>
>
> ---------------------------------------------------------------------
> 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: [PROPOSAL] Etch
Posted by James Dixson <ja...@cisco.com>.
The watercooler problem is real, but addressable. We accept that in order
for a community around Etch to grow, communication has to be open. Much of
our communication and discussion about Etch has been mediated over email as
our intramural community is geographically distributed. It is not a stretch
for us to change our primary discussion mailers.
--
james
On 8/1/08 4:29 AM, "Henning Schmiedehausen" <he...@apache.org> wrote:
> You adressed the two concerns that I have, too, thanks.
>
> - The name. "Debian Etch" is a deeply engrained meme with the "Etch"
> short cut.
>
> - Office disussions. Projects where a large number of committers are
> from the same organization and that also have this company being
> invested in the project might fall into the "watercooler discussion"
> trap. Or into the "this is a patch for <foo>, I discussed and reviewed
> it with <few other committers> and they think it is fine" problem, where
> the review and discussion happened off the mailing list.
>
> It is definitely painful if you have the large majority of committers
> and contributors in the office to still send out stuff to the mailing
> lists, wait for people in other time zones to catch up and then go
> ahead. In fast moving projects (I'm talking about you, Shindig
> people. ;-) ), the aspect of a global distributed community sometimes
> gets forgotten if you have all the relevant people in the next room. So
> this is something that should be watched during incubation.
>
> Apart from that: Wow, cool product. +1 for incubation.
>
> Ciao
> Henning
>
>
> On Fri, 2008-08-01 at 11:28 +0800, Niclas Hedhman wrote:
>> On Friday 01 August 2008 00:16, James Dixson wrote:
>>> This a proposal to enter Etch in to the incubator.
>>>
>>> See http://wiki.apache.org/incubator/EtchProposal for updates.
>>>
>>> In particular, we are looking for an interested Champion.
>>
>> Well, you are expected to have found a Champion prior to submitting the
>> proposal, but that is not a blocker.
>>
>> "Etch" --> Not so sure. "Debian Etch vs Apache Etch, which one is better?"
>> Doh... I would seek another name.
>>
>> I like this proposal a lot, probably because of too many fingers burned on
>> SOAP. The challenge will be community building, and I have two fears;
>> 1. Codebase might be "too good".
>> 2. "At office" discussions on progress.
>>
>> Well, I am willing to be a Mentor on this podling if accepted. List me as
>> Champion if you don't get anyone else. And you are effectively requesting the
>> Incubator PMC to be the Sponsor.
>>
>>
>> My +1 for Incubation.
>>
>>
>> Cheers
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
--
James Dixson
Manager, Software Development
CUAE Engineering, Cisco Systems
(e) jadixson@cisco.com
(p) 512-336-3305
(m) 512-968-2116
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by Henning Schmiedehausen <he...@apache.org>.
You adressed the two concerns that I have, too, thanks.
- The name. "Debian Etch" is a deeply engrained meme with the "Etch"
short cut.
- Office disussions. Projects where a large number of committers are
from the same organization and that also have this company being
invested in the project might fall into the "watercooler discussion"
trap. Or into the "this is a patch for <foo>, I discussed and reviewed
it with <few other committers> and they think it is fine" problem, where
the review and discussion happened off the mailing list.
It is definitely painful if you have the large majority of committers
and contributors in the office to still send out stuff to the mailing
lists, wait for people in other time zones to catch up and then go
ahead. In fast moving projects (I'm talking about you, Shindig
people. ;-) ), the aspect of a global distributed community sometimes
gets forgotten if you have all the relevant people in the next room. So
this is something that should be watched during incubation.
Apart from that: Wow, cool product. +1 for incubation.
Ciao
Henning
On Fri, 2008-08-01 at 11:28 +0800, Niclas Hedhman wrote:
> On Friday 01 August 2008 00:16, James Dixson wrote:
> > This a proposal to enter Etch in to the incubator.
> >
> > See http://wiki.apache.org/incubator/EtchProposal for updates.
> >
> > In particular, we are looking for an interested Champion.
>
> Well, you are expected to have found a Champion prior to submitting the
> proposal, but that is not a blocker.
>
> "Etch" --> Not so sure. "Debian Etch vs Apache Etch, which one is better?"
> Doh... I would seek another name.
>
> I like this proposal a lot, probably because of too many fingers burned on
> SOAP. The challenge will be community building, and I have two fears;
> 1. Codebase might be "too good".
> 2. "At office" discussions on progress.
>
> Well, I am willing to be a Mentor on this podling if accepted. List me as
> Champion if you don't get anyone else. And you are effectively requesting the
> Incubator PMC to be the Sponsor.
>
>
> My +1 for Incubation.
>
>
> Cheers
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by "Louis R. Marascio" <lo...@fitnr.com>.
Niclas Hedhman <ni...@hedhman.org> wrote:
>On Friday 01 August 2008 21:10, James Dixson wrote:
>> I am a bit confused though about the "too good" concern, I do not think I
>> understand what you mean. Could you elaborate?
>
>I think it was Stefano Mazzocchi who said about community building, that the
>only "Bad Code + Great Vision" will succeed in building strong communities.
>It refers to the fact that there must be "itches to scratch" for a lot of
>people, otherwise they just stay users and the momentum of the project never
>really get going...
Niclas,
Point taken. As you and a few others have pointed out, building a
community is one of the challenges here, but it is also one of the areas
that we have some experience with. At Cisco the product we build is for
developers. While it isn't open source it still relies on an active
community of developers--one that we've fostered and grown on our own
accord here at Cisco. You can see it here:
http://tech.groups.yahoo.com/group/cuae-dev/
Again, I realize it isn't the same, but I wanted to make sure the
Incubator community knows that the folks who are bringing Etch to Apache
for consideration do have experience in building a community of
developers.
Thanks again for your offer of support.
Louis
--
Louis R. Marascio - www.fitnr.com
... fixed in the next release ...
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by James Dixson <ja...@cisco.com>.
Ah. Well, then I do not think there is anything to worry about as far as
Etch is concerned. There are many, many potential growth points for the
project. A simple example, Etch supports Java and C# language bindings today
with a binary-transport. One of the committers, Seth Call, is working on a
JavaScript language-binding with a JSON-encoded transport. I am working on a
Python binding. Language bindings and transport plugins represent huge
"itches". Furthermore, even our own limited experience has show that even
when one architects language and transport neutrality, we miss stuff. The
python language binding work early on inspired etch changes and
binary-transport changes to better support dynamically typed languages.
Other dimensions of "itches" exists in the management and aggregation of
multiple instances of services. IS-A vs HAS-A relationships between
services. Session management. Service discovery, etc.
IMHO while etch-1.0 offers capabilities today that fix a lot of problems in
the way services are defined, implemented and consumed. I do not by any
means think it eliminates problems from this space entirely. I think was
Etch offers is a more efficient refactoring of the problem of network
service creation and development and in turn "opens the field" to a
completely new class of technological challenges and opportunities.
--
James
On 8/1/08 8:50 AM, "Niclas Hedhman" <ni...@hedhman.org> wrote:
> On Friday 01 August 2008 21:10, James Dixson wrote:
>> I am a bit confused though about the "too good" concern, I do not think I
>> understand what you mean. Could you elaborate?
>
> I think it was Stefano Mazzocchi who said about community building, that the
> only "Bad Code + Great Vision" will succeed in building strong communities.
> It refers to the fact that there must be "itches to scratch" for a lot of
> people, otherwise they just stay users and the momentum of the project never
> really get going...
>
>
> Cheers
--
James Dixson
Manager, Software Development
CUAE Engineering, Cisco Systems
(e) jadixson@cisco.com
(p) 512-336-3305
(m) 512-968-2116
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 01 August 2008 21:10, James Dixson wrote:
> I am a bit confused though about the "too good" concern, I do not think I
> understand what you mean. Could you elaborate?
I think it was Stefano Mazzocchi who said about community building, that the
only "Bad Code + Great Vision" will succeed in building strong communities.
It refers to the fact that there must be "itches to scratch" for a lot of
people, otherwise they just stay users and the momentum of the project never
really get going...
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by James Dixson <ja...@cisco.com>.
Niclas, thanks for the support it is much appreciated. I will put you down
as as 'willing' on Mentor and Champion.
I understand the "at office" concern, it is a mode of operation and we (the
committers) all understand the importance of public communication and
consensus.
I am a bit confused though about the "too good" concern, I do not think I
understand what you mean. Could you elaborate?
--
james
On 7/31/08 10:28 PM, "Niclas Hedhman" <ni...@hedhman.org> wrote:
> On Friday 01 August 2008 00:16, James Dixson wrote:
>> This a proposal to enter Etch in to the incubator.
>>
>> See http://wiki.apache.org/incubator/EtchProposal for updates.
>>
>> In particular, we are looking for an interested Champion.
>
> Well, you are expected to have found a Champion prior to submitting the
> proposal, but that is not a blocker.
>
> "Etch" --> Not so sure. "Debian Etch vs Apache Etch, which one is better?"
> Doh... I would seek another name.
>
> I like this proposal a lot, probably because of too many fingers burned on
> SOAP. The challenge will be community building, and I have two fears;
> 1. Codebase might be "too good".
> 2. "At office" discussions on progress.
>
> Well, I am willing to be a Mentor on this podling if accepted. List me as
> Champion if you don't get anyone else. And you are effectively requesting the
> Incubator PMC to be the Sponsor.
>
>
> My +1 for Incubation.
>
>
> Cheers
--
James Dixson
Manager, Software Development
CUAE Engineering, Cisco Systems
(e) jadixson@cisco.com
(p) 512-336-3305
(m) 512-968-2116
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 01 August 2008 00:16, James Dixson wrote:
> This a proposal to enter Etch in to the incubator.
>
> See http://wiki.apache.org/incubator/EtchProposal for updates.
>
> In particular, we are looking for an interested Champion.
Well, you are expected to have found a Champion prior to submitting the
proposal, but that is not a blocker.
"Etch" --> Not so sure. "Debian Etch vs Apache Etch, which one is better?"
Doh... I would seek another name.
I like this proposal a lot, probably because of too many fingers burned on
SOAP. The challenge will be community building, and I have two fears;
1. Codebase might be "too good".
2. "At office" discussions on progress.
Well, I am willing to be a Mentor on this podling if accepted. List me as
Champion if you don't get anyone else. And you are effectively requesting the
Incubator PMC to be the Sponsor.
My +1 for Incubation.
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Poloka
Posted by Rajith Attapattu <ra...@gmail.com>.
I am quite happy to be a mentor and help out with the project on a voluntary
basis.
I have gone through the mill with Apache Qpid and to a certain extent with
Synapse/Axis2/Tuscany, so familiar with the process.
However I have to note that I have an affiliation with the University of
Toronto's Middleware Systems
Research Group as a student and have done work with the code base etc as
part of a research course.
If the above affiliation is not an issue then I am quite happy to put down
my name as a mentor.
Regards,
Rajith
On Mon, Aug 18, 2008 at 1:10 PM, Mankovskii, Serge
<Se...@ca.com>wrote:
> This is a proposal to enter Poloka in to the incubator.
>
> See http://wiki.apache.org/incubator/PolokaProposal
>
> We do not have a champion at the moment.
>
> We are looking forward to the community input.
>
>
> Cheers
> Serge Mankovski
> --------------
>
> = POLOKA Project Proposal =
>
>
> == Abstract ==
>
> Poloka will be a standalone reference implementation of the
> WS-BaseNotification, WS-Topics and the WS-BrokeredNotification
> standards. It is aiming to go beyond the WS-BrokeredNotification
> specification and deliver a reliable and scalable network of
> WS-BrokeredNotification brokers. All existing implementations of
> WS-BrokeredNotification focus on implementation of a message broker.
> Poloka will implement additional features that would allow for a
> federation of brokers. It will extend WS-BrokeredNotification
> specification with the notion of a federated broker network and allow
> for a reliable, a scalable and a highly available implementation of the
> WS-BrokeredNotification standard.
>
> == Proposal ==
>
> Poloka will provide a reference implementation of WS-BaseNotification,
> WS-Topics and WS-BrokeredNotification standards. The project will
> provide a clear separation of functionality required by the existing
> standards from additional functionality provided as an enhancement and
> elaboration on the standards
>
> Poloka will:
> 1. not be tightly coupled with WS-RF and WSDM standards
> 1. implement the WS-BrokeredNotification specification absent in
> the Apache Muse project
> 1. will implement a network of brokers that will provide
> scalability, reliability and fault tolerance
> 1. feed implementation and design experiences into the OASIS
> standards process and might lead to new revisions of the WS-Notification
> stack of standards
>
> == Background ==
>
> Poloka is a second generation of the research project going on for the
> last five years at the University of Toronto's Middleware Systems
> Research Group under the
> [http://research.msrg.utoronto.ca/Padres/WebHome PADRES] project.
> During these years the group developed a stable code base that will form
> a base for the first release of Poloka.
>
> The PADRES project has developed a number of new technologies that allow
> for a scalable and reliable federation of publish/subscribe brokers. The
> PADRES federation mechanisms allow for redundant message routing, load
> balancing, complex event processing and other useful features that
> become available to the federated network of the WS-BrokeredNotification
> brokers.
>
> The project was started before WS-BrokeredNotification standard was
> created. The initial release of Poloka will contain existing PADRES code
> that does not use any WS-* compliant interfaces. However that will
> change with the future releases. PADRES brokers will be enriched with
> the WS--Notification interfaces on the notification producer and
> notification consumer side. The Broker-to-Broker communication side of
> communication is not covered by any existing standards to date and it
> would remain non-WS based.
>
> The team engaged in the development of Poloka involves two former
> participants of the OASIS committee that produced WS-BaseNotification,
> WS-Topics and WS-BrokeredNotification standards. Their engagement would
> serve dual purposes: to serve as source if first-hand authoritative
> knowledge of the standards and as a conduit for the standards use
> experience that might result in future evolution of the
> WS-BaseNotification, WS-Topics and WS-BrokeredNotification standards.
>
> A note about the project name; we are inspired by the impact WikiWiki
> made on the world of web applications. We followed the naming exampled
> set by author of the Wiki and simply translated word "Broker" using a
> Hawaiian dictionary. Poloka simply means "Broker"
>
> == Rationale ==
>
> Current adoption of the WS-Notification set of standard is impeded by
> absence of a standalone reference implementation. For example
> WS-Notification implementation in Apache Muse is incomplete and tightly
> coupled with programming model of WS-RF specification. It is also
> packaged within WSDM implementation. Poloka aims to provide a "clean"
> implementation not tied to other standards as a part of WS-Commons.
>
> The PADRES group have over the years received a number of requests to
> release existing code into open source. We are looking forward to Apache
> foundation and its organizing principles as a vehicle for creation of a
> successful community that would connecting all people already interested
> in the release of the code into open source.
>
> The project will follow new standards and specifications that are coming
> up in the space of web-services based messaging.
>
> == Initial Goals ==
>
> 1. Initial release of the PADRES codebase to Apache Poloka
> 1. Implementation of the WS-Base Notification, WS-Topics and
> WS-Brokered Notification interfaces
> 1. Creation of a reference implementation of the standards with
> non-federated brokers
> 1. Implement Poloka federation based on the functions of the PADRES
> brokers
>
> == Current Status ==
>
> The PADRES project has developed a stable code base and a number of
> systems are built using this code base. These systems are deployed on
> PlanetLab and within the PADRES lab infrastructure (cluster with 25+
> machines). Future deployments on the Amazon Computing Cloud are under
> investigation. This code will become a base for the initial release of
> Poloka. The team conducted a survey of licensed code used within the
> existing code base. The code base can be brought up in compliance with
> Apache licensing policy without much effort. One of the members of our
> team is already working on the implementation of the
> WS-BaseNotification, WS-Topics and WS-BrokeredNotification interfaces.
> Remaining team members are preparing for the code release.
>
> There is one patent application submitted to the US patent office that
> covers use of the federated publish/subscribe infrastructure for
> Enterprise Job Scheduling. The team is currently working with the
> respective IP owners on the patent to ensure compliance with the Apache
> licensing policy.
>
> == Meritocracy ==
>
> The project was originally started in 2002 by Prof. Hans-Arno Jacobsen
> and Serge Mankovski under sponsorship of CA Inc (formerly Computer
> Associates), Ontario Centers of Excellence (formerly known as CITO) and
> the National Science and Engineering Research Council of Canada. Since
> then the project is growing and it became known and respected in the
> area of distributed event processing and messaging middleware.
>
> == Community ==
>
> Over the years a number of companies expressed interest in this work. At
> the moment project research activities are conducted in collaboration
> with CA Inc (formerly Computer Associates), IBM, Sun, and Bell Canada,
> and the Chinese Academy of Science. The project is managed and organized
> within the Middleware Systems Research Group at the University of
> Toronto.
>
> The community is built around the papers and publications produced by
> the research community and also by conferences and workshops where the
> project is presented.
>
>
> == Mentors ==
>
> * Dr. Hans-Arno Jacobsen is the head of the Middleware Systems Research
> Group and he is leading all current research activities.
>
> * Serge Mankovski is mentoring the project on issues of Network and
> Systems Management, Security, Governance and Complex Event Processing.
>
> * Mark Weitzel provides guidance to make sure that the output is
> appropriate for the industrial participants.
>
> * Peter Niblett is one of the editors of the WS-BaseNotification,
> WS-Topics and WS-BrokeredNotification standards committee and mentoring
> the team on these technologies.
>
> * Dr. Kirk Wilson is a member of the WS-BaseNotification, WS-Topics
> and WS-BrokeredNotification standards committee and mentoring the team
> on these technologies.
>
> == Core Developers ==
>
> * Dr. Balasubramaneyam Maniymaran is developing mechanisms for Complex
> Event Processing using the PADRES system
> * Vinod Muthusamy is developing publish/subscribe matching algorithms
> and routing protocls,
> * Alex Cheung is developing load balancing and scalability features of
> the broker federation.
> * Guoli Li is developing composite subscription matching, message
> routing and historic data access
> * Reza Sherafat is developing reliability, scalability, fault tolerance
> and self-healing features of the broker federation
> * Naweed Tajuddin is developing WS-BaseNotification, WS-Topics and
> WS-BrokeredNotification interfaces.
> * Dr. Songlin Hu is developing business process automation solutions
> using the PADRES system
>
> == Alignments ==
>
> Apache goals, mode of operation and development focus of the WS-Commons
> project provide an attractive framework for the inevitable release of
> the existing code base to Open Source communities. We are planning to
> use Apache Axis2 code as the base for our WS-enabled broker. The
> existing team of core developers and project supporters include
> representatives of several companies and Apache license is conducive to
> their future engagement in the project. There is an existing contact and
> working relationships with the Apache Muse project as well.
>
> == Known Risks ==
>
> === Orphaned Projects ===
>
> Initial contributors are from major software companies and from the
> university research community. The development of the related code base
> has been steadily growing over the last five years and there is no risk.
> There are a number of requests from various individuals for the Open
> Source code developed by the project. We expect that these individuals
> will join this project once it becomes publicly available. Current
> interest in the project gives us confidence that the community will be
> able to broaden the committer base in the future.
> Inexperience with Open Source
>
> The core development team has varied degrees of experience with open
> source. Some of the developers released open source code in the past. We
> are hoping that Apache PMC and Mentors will help us to get us started
> and "hold our hand" until we gained sufficient experience.
>
> The Middleware Systems Research Group has released other open source
> projects, such as the AspectC project (about 3500 downloads to date over
> a period of 2 years and 8 releases.) AspetC.net is released under GPL
> (it is based on GPLed components.)
>
> === Homogeneous Developers ===
>
> Most of the current core developers do not work for a commercial entity.
> They are working on the project because it is a subject of their
> research and will result in PhD and Master Degrees at some point in the
> future. Other core developers are working for CA and IBM and the Chinese
> Academy of Sciences.
>
> The team is collecting a list of persons and institutions that expressed
> interest in open source implantation of PADRES over the years. We expect
> that this list would give us a good start in building the community
> during the incubation period.
>
> === Documentation ===
>
> Available in form of publications here
> http://padres.msrg.toronto.edu/Padres/
>
> === Initial Source ===
>
> Initial source is currently in the closed source state.
>
> === Source and Intellectual Property Submission Plan ===
>
> The project is currently conducted under terms of a collaboration
> agreement between the University of Toronto, CA Canada Company, Sun
> Microsystems, and the Ontario Centers of Excellence, and includes a
> clause to permit the release of the project IP into open source under
> the Eclipse license. However, under current considerations, we think
> that the Apache community is more closely aligned with the needs and
> goals of the project. Since the Apache license offers very similar IP
> terms, it would be acceptable to release the IP under the Apache
> license. The team will produce a Certificate of Originality in respect
> to all the code released to Apache.
>
> === External Dependencies ===
>
> Currently PADRES code relies on Jess expert system shell distributed
> under a commercial license by Sandia National Labs. The team will remove
> this dependency before the initial release into incubation by
> implementing our own version of RETE matching engine.
>
> Other code dependencies are:
> * openjms.jar Exolab License
> * exolabcore 0.3.5.jar: Exolab license
> * j2ee.jar: Apache license v2.0
> * commons-collections.jar: Apache license v2.0 It uses jung-1.7.6.ja
> * concurrent.jar: SUN license It uses jung-1.7.6.jar.
> * junit.jar: Common Public License v1.0
> * log4j-1.2.13.jar: Apache license v2.0
> * mysql-connector.jar: GNU General Public license
> * pg73jdbc3.jar: BSD license
>
> Dependency on Exolab, GNU, BSD and Sun licensed code is localized and
> non-essential.
>
> === Cryptography ===
>
> Some of the aspects of secure message transport include message
> encryption
>
> === Required Resources ===
>
> * Mailing Lists - there are two mailing lists
> * Subversion Directory - it exists, but it is not available outside of
> the Middleware Systems Research Group
> * Issue Tracking - it exists, but it is not available outside of the
> Middleware Research Systems Group
> * Other Resources
>
> == Initial Committers ==
>
> * Arno Jacobsen
> * Serge Mankovski
> * NaweedTajuddin
> * Balasubramaneyam Maniymaran
> * Vinod Muthusamy
> * Alex Cheung
> * Guoli Li
> * Reza Sherafat
>
>
> == Affiliations ==
> * Hans-Arno Jacobsen - University of Toronto
> * Serge Mankovski - CA Labs
> * Kirk Wilson - CA Labs
> * Peter Niblett - IBM
> * Mark Weitzel - IBM
> * Naweed Tajuddin - University of Toronto
> * Balasubramaneyam Maniymaran - University of Toronto
> * Vinod Muthusamy - University of Toronto
> * Alex Cheung - University of Toronto
> * Guoli Li - University of Toronto
> * Reza Sherafat - University of Toronto
> * Shuang Hou - Academy of Science of China
>
>
>
> == Sponsors ==
> * Champion TBD
> * Nominated Mentors TBD
> * Sponsoring Entity TBD, but we think we should be somewhere in
> WS-Commons
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
[PROPOSAL] Poloka
Posted by "Mankovskii, Serge" <Se...@ca.com>.
This is a proposal to enter Poloka in to the incubator.
See http://wiki.apache.org/incubator/PolokaProposal
We do not have a champion at the moment.
We are looking forward to the community input.
Cheers
Serge Mankovski
--------------
= POLOKA Project Proposal =
== Abstract ==
Poloka will be a standalone reference implementation of the
WS-BaseNotification, WS-Topics and the WS-BrokeredNotification
standards. It is aiming to go beyond the WS-BrokeredNotification
specification and deliver a reliable and scalable network of
WS-BrokeredNotification brokers. All existing implementations of
WS-BrokeredNotification focus on implementation of a message broker.
Poloka will implement additional features that would allow for a
federation of brokers. It will extend WS-BrokeredNotification
specification with the notion of a federated broker network and allow
for a reliable, a scalable and a highly available implementation of the
WS-BrokeredNotification standard.
== Proposal ==
Poloka will provide a reference implementation of WS-BaseNotification,
WS-Topics and WS-BrokeredNotification standards. The project will
provide a clear separation of functionality required by the existing
standards from additional functionality provided as an enhancement and
elaboration on the standards
Poloka will:
1. not be tightly coupled with WS-RF and WSDM standards
1. implement the WS-BrokeredNotification specification absent in
the Apache Muse project
1. will implement a network of brokers that will provide
scalability, reliability and fault tolerance
1. feed implementation and design experiences into the OASIS
standards process and might lead to new revisions of the WS-Notification
stack of standards
== Background ==
Poloka is a second generation of the research project going on for the
last five years at the University of Toronto's Middleware Systems
Research Group under the
[http://research.msrg.utoronto.ca/Padres/WebHome PADRES] project.
During these years the group developed a stable code base that will form
a base for the first release of Poloka.
The PADRES project has developed a number of new technologies that allow
for a scalable and reliable federation of publish/subscribe brokers. The
PADRES federation mechanisms allow for redundant message routing, load
balancing, complex event processing and other useful features that
become available to the federated network of the WS-BrokeredNotification
brokers.
The project was started before WS-BrokeredNotification standard was
created. The initial release of Poloka will contain existing PADRES code
that does not use any WS-* compliant interfaces. However that will
change with the future releases. PADRES brokers will be enriched with
the WS--Notification interfaces on the notification producer and
notification consumer side. The Broker-to-Broker communication side of
communication is not covered by any existing standards to date and it
would remain non-WS based.
The team engaged in the development of Poloka involves two former
participants of the OASIS committee that produced WS-BaseNotification,
WS-Topics and WS-BrokeredNotification standards. Their engagement would
serve dual purposes: to serve as source if first-hand authoritative
knowledge of the standards and as a conduit for the standards use
experience that might result in future evolution of the
WS-BaseNotification, WS-Topics and WS-BrokeredNotification standards.
A note about the project name; we are inspired by the impact WikiWiki
made on the world of web applications. We followed the naming exampled
set by author of the Wiki and simply translated word "Broker" using a
Hawaiian dictionary. Poloka simply means "Broker"
== Rationale ==
Current adoption of the WS-Notification set of standard is impeded by
absence of a standalone reference implementation. For example
WS-Notification implementation in Apache Muse is incomplete and tightly
coupled with programming model of WS-RF specification. It is also
packaged within WSDM implementation. Poloka aims to provide a "clean"
implementation not tied to other standards as a part of WS-Commons.
The PADRES group have over the years received a number of requests to
release existing code into open source. We are looking forward to Apache
foundation and its organizing principles as a vehicle for creation of a
successful community that would connecting all people already interested
in the release of the code into open source.
The project will follow new standards and specifications that are coming
up in the space of web-services based messaging.
== Initial Goals ==
1. Initial release of the PADRES codebase to Apache Poloka
1. Implementation of the WS-Base Notification, WS-Topics and
WS-Brokered Notification interfaces
1. Creation of a reference implementation of the standards with
non-federated brokers
1. Implement Poloka federation based on the functions of the PADRES
brokers
== Current Status ==
The PADRES project has developed a stable code base and a number of
systems are built using this code base. These systems are deployed on
PlanetLab and within the PADRES lab infrastructure (cluster with 25+
machines). Future deployments on the Amazon Computing Cloud are under
investigation. This code will become a base for the initial release of
Poloka. The team conducted a survey of licensed code used within the
existing code base. The code base can be brought up in compliance with
Apache licensing policy without much effort. One of the members of our
team is already working on the implementation of the
WS-BaseNotification, WS-Topics and WS-BrokeredNotification interfaces.
Remaining team members are preparing for the code release.
There is one patent application submitted to the US patent office that
covers use of the federated publish/subscribe infrastructure for
Enterprise Job Scheduling. The team is currently working with the
respective IP owners on the patent to ensure compliance with the Apache
licensing policy.
== Meritocracy ==
The project was originally started in 2002 by Prof. Hans-Arno Jacobsen
and Serge Mankovski under sponsorship of CA Inc (formerly Computer
Associates), Ontario Centers of Excellence (formerly known as CITO) and
the National Science and Engineering Research Council of Canada. Since
then the project is growing and it became known and respected in the
area of distributed event processing and messaging middleware.
== Community ==
Over the years a number of companies expressed interest in this work. At
the moment project research activities are conducted in collaboration
with CA Inc (formerly Computer Associates), IBM, Sun, and Bell Canada,
and the Chinese Academy of Science. The project is managed and organized
within the Middleware Systems Research Group at the University of
Toronto.
The community is built around the papers and publications produced by
the research community and also by conferences and workshops where the
project is presented.
== Mentors ==
* Dr. Hans-Arno Jacobsen is the head of the Middleware Systems Research
Group and he is leading all current research activities.
* Serge Mankovski is mentoring the project on issues of Network and
Systems Management, Security, Governance and Complex Event Processing.
* Mark Weitzel provides guidance to make sure that the output is
appropriate for the industrial participants.
* Peter Niblett is one of the editors of the WS-BaseNotification,
WS-Topics and WS-BrokeredNotification standards committee and mentoring
the team on these technologies.
* Dr. Kirk Wilson is a member of the WS-BaseNotification, WS-Topics
and WS-BrokeredNotification standards committee and mentoring the team
on these technologies.
== Core Developers ==
* Dr. Balasubramaneyam Maniymaran is developing mechanisms for Complex
Event Processing using the PADRES system
* Vinod Muthusamy is developing publish/subscribe matching algorithms
and routing protocls,
* Alex Cheung is developing load balancing and scalability features of
the broker federation.
* Guoli Li is developing composite subscription matching, message
routing and historic data access
* Reza Sherafat is developing reliability, scalability, fault tolerance
and self-healing features of the broker federation
* Naweed Tajuddin is developing WS-BaseNotification, WS-Topics and
WS-BrokeredNotification interfaces.
* Dr. Songlin Hu is developing business process automation solutions
using the PADRES system
== Alignments ==
Apache goals, mode of operation and development focus of the WS-Commons
project provide an attractive framework for the inevitable release of
the existing code base to Open Source communities. We are planning to
use Apache Axis2 code as the base for our WS-enabled broker. The
existing team of core developers and project supporters include
representatives of several companies and Apache license is conducive to
their future engagement in the project. There is an existing contact and
working relationships with the Apache Muse project as well.
== Known Risks ==
=== Orphaned Projects ===
Initial contributors are from major software companies and from the
university research community. The development of the related code base
has been steadily growing over the last five years and there is no risk.
There are a number of requests from various individuals for the Open
Source code developed by the project. We expect that these individuals
will join this project once it becomes publicly available. Current
interest in the project gives us confidence that the community will be
able to broaden the committer base in the future.
Inexperience with Open Source
The core development team has varied degrees of experience with open
source. Some of the developers released open source code in the past. We
are hoping that Apache PMC and Mentors will help us to get us started
and "hold our hand" until we gained sufficient experience.
The Middleware Systems Research Group has released other open source
projects, such as the AspectC project (about 3500 downloads to date over
a period of 2 years and 8 releases.) AspetC.net is released under GPL
(it is based on GPLed components.)
=== Homogeneous Developers ===
Most of the current core developers do not work for a commercial entity.
They are working on the project because it is a subject of their
research and will result in PhD and Master Degrees at some point in the
future. Other core developers are working for CA and IBM and the Chinese
Academy of Sciences.
The team is collecting a list of persons and institutions that expressed
interest in open source implantation of PADRES over the years. We expect
that this list would give us a good start in building the community
during the incubation period.
=== Documentation ===
Available in form of publications here
http://padres.msrg.toronto.edu/Padres/
=== Initial Source ===
Initial source is currently in the closed source state.
=== Source and Intellectual Property Submission Plan ===
The project is currently conducted under terms of a collaboration
agreement between the University of Toronto, CA Canada Company, Sun
Microsystems, and the Ontario Centers of Excellence, and includes a
clause to permit the release of the project IP into open source under
the Eclipse license. However, under current considerations, we think
that the Apache community is more closely aligned with the needs and
goals of the project. Since the Apache license offers very similar IP
terms, it would be acceptable to release the IP under the Apache
license. The team will produce a Certificate of Originality in respect
to all the code released to Apache.
=== External Dependencies ===
Currently PADRES code relies on Jess expert system shell distributed
under a commercial license by Sandia National Labs. The team will remove
this dependency before the initial release into incubation by
implementing our own version of RETE matching engine.
Other code dependencies are:
* openjms.jar Exolab License
* exolabcore 0.3.5.jar: Exolab license
* j2ee.jar: Apache license v2.0
* commons-collections.jar: Apache license v2.0 It uses jung-1.7.6.ja
* concurrent.jar: SUN license It uses jung-1.7.6.jar.
* junit.jar: Common Public License v1.0
* log4j-1.2.13.jar: Apache license v2.0
* mysql-connector.jar: GNU General Public license
* pg73jdbc3.jar: BSD license
Dependency on Exolab, GNU, BSD and Sun licensed code is localized and
non-essential.
=== Cryptography ===
Some of the aspects of secure message transport include message
encryption
=== Required Resources ===
* Mailing Lists - there are two mailing lists
* Subversion Directory - it exists, but it is not available outside of
the Middleware Systems Research Group
* Issue Tracking - it exists, but it is not available outside of the
Middleware Research Systems Group
* Other Resources
== Initial Committers ==
* Arno Jacobsen
* Serge Mankovski
* NaweedTajuddin
* Balasubramaneyam Maniymaran
* Vinod Muthusamy
* Alex Cheung
* Guoli Li
* Reza Sherafat
== Affiliations ==
* Hans-Arno Jacobsen - University of Toronto
* Serge Mankovski - CA Labs
* Kirk Wilson - CA Labs
* Peter Niblett - IBM
* Mark Weitzel - IBM
* Naweed Tajuddin - University of Toronto
* Balasubramaneyam Maniymaran - University of Toronto
* Vinod Muthusamy - University of Toronto
* Alex Cheung - University of Toronto
* Guoli Li - University of Toronto
* Reza Sherafat - University of Toronto
* Shuang Hou - Academy of Science of China
== Sponsors ==
* Champion TBD
* Nominated Mentors TBD
* Sponsoring Entity TBD, but we think we should be somewhere in
WS-Commons
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by James Dixson <ja...@cisco.com>.
Thanks for the support Paul!
--
james
On 8/6/08 4:58 AM, "Paul Fremantle" <pz...@gmail.com> wrote:
> James
>
> I'm +1 for incubation. I see you have three mentors, but if at some
> future point you need another mentor, I would be very happy to step
> in.
>
> Regards,
> Paul
>
> On Tue, Aug 5, 2008 at 9:33 PM, Niklas Gustavsson <ni...@protocol7.com>
> wrote:
>> On Thu, Jul 31, 2008 at 6:16 PM, James Dixson <ja...@cisco.com> wrote:
>>> This a proposal to enter Etch in to the incubator.
>>>
>>> See http://wiki.apache.org/incubator/EtchProposal for updates.
>>
>> +1 for incubation (non-binding). While I find this area to be a bit
>> overcrowded lately, having both Etch and Thrift at Apache and Protocol
>> buffers under ASL 2.0 does offer some interesting opportunities for
>> competition as well as cooperation.
>>
>> I do share the concerns about naming conflicts. Debian is by far more
>> well known and trying to establish this project under a conflicting
>> name would be hard.
>>
>> /niklas
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
--
James Dixson
Manager, Software Development
CUAE Engineering, Cisco Systems
(e) jadixson@cisco.com
(p) 512-336-3305
(m) 512-968-2116
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Etch
Posted by Paul Fremantle <pz...@gmail.com>.
James
I'm +1 for incubation. I see you have three mentors, but if at some
future point you need another mentor, I would be very happy to step
in.
Regards,
Paul
On Tue, Aug 5, 2008 at 9:33 PM, Niklas Gustavsson <ni...@protocol7.com> wrote:
> On Thu, Jul 31, 2008 at 6:16 PM, James Dixson <ja...@cisco.com> wrote:
>> This a proposal to enter Etch in to the incubator.
>>
>> See http://wiki.apache.org/incubator/EtchProposal for updates.
>
> +1 for incubation (non-binding). While I find this area to be a bit
> overcrowded lately, having both Etch and Thrift at Apache and Protocol
> buffers under ASL 2.0 does offer some interesting opportunities for
> competition as well as cooperation.
>
> I do share the concerns about naming conflicts. Debian is by far more
> well known and trying to establish this project under a conflicting
> name would be hard.
>
> /niklas
>
> ---------------------------------------------------------------------
> 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: [PROPOSAL] Etch
Posted by Henning Schmiedehausen <hp...@intermeta.de>.
Call it "Edge". :-)
My concern is mainly "2". And you will get lots of Linux support
questions on your mailing list.
Ciao
Henning
James Dixson (jadixson) schrieb:
> I have heard the name concern a couple of times now...
>
> When we picked the name Etch about 18 months ago, we knew about the
> Debian release, but frankly we were unconcerned. Debian etch is the name
> of a release of Debian, no different than "4" being a release of Fedora.
> Eventually Debian etch will fade into memory just as sarge and woody
> have.
>
> Etch, in our line of thinking (if it could be said we were doing any
> thinking :-) ) was the name we were giving to the technology, not a
> release. There were no other technologies named Etch or similar, so we
> declared victory and moved on.
>
> So I guess my question back to everyone is this:
>
> What is the concern about the name Etch, really?
>
> 1. Is there a legal trademark issue or a formal Apache branding policy
> issue with using the name Etch such that the use of the name is simply
> not going to be allowed.
>
> - or -
>
> 2. Is there a concern that during incubation, we might have to be
> explicit in communication and always say "Apache Etch" rather than just
> "Etch" because of a fear that a reference to "Etch", taken out of
> context, could be confused with Debian 4.0?
>
> If "1" is true then, absolutely the name should be changed.
>
> But if only "2" is true, then I will need a bit more convincing. I am
> after all very, very lazy and changing the name of a working toolset is
> well... work :-)
>
>
> ---
> James Dixson
> Manager, Software Development
> CUAE Engineering, Cisco Systems Inc.
> Direct: 512-336-3305
> Mobile: 512-968-2116
> james.dixson@cisco.com
>
> -----Original Message-----
> From: Niklas Gustavsson [mailto:niklas@protocol7.com]
> Sent: Tuesday, August 05, 2008 3:33 PM
> To: general@incubator.apache.org
> Subject: Re: [PROPOSAL] Etch
>
> On Thu, Jul 31, 2008 at 6:16 PM, James Dixson <ja...@cisco.com>
> wrote:
>> This a proposal to enter Etch in to the incubator.
>>
>> See http://wiki.apache.org/incubator/EtchProposal for updates.
>
> +1 for incubation (non-binding). While I find this area to be a bit
> overcrowded lately, having both Etch and Thrift at Apache and Protocol
> buffers under ASL 2.0 does offer some interesting opportunities for
> competition as well as cooperation.
>
> I do share the concerns about naming conflicts. Debian is by far more
> well known and trying to establish this project under a conflicting
> name would be hard.
>
> /niklas
>
> ---------------------------------------------------------------------
> 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
>
--
Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person
Open Source Consulting, Development, Design | Velocity - Turbine
"Save the cheerleader. Save the world."
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [PROPOSAL] Etch
Posted by "James Dixson (jadixson)" <ja...@cisco.com>.
I have heard the name concern a couple of times now...
When we picked the name Etch about 18 months ago, we knew about the
Debian release, but frankly we were unconcerned. Debian etch is the name
of a release of Debian, no different than "4" being a release of Fedora.
Eventually Debian etch will fade into memory just as sarge and woody
have.
Etch, in our line of thinking (if it could be said we were doing any
thinking :-) ) was the name we were giving to the technology, not a
release. There were no other technologies named Etch or similar, so we
declared victory and moved on.
So I guess my question back to everyone is this:
What is the concern about the name Etch, really?
1. Is there a legal trademark issue or a formal Apache branding policy
issue with using the name Etch such that the use of the name is simply
not going to be allowed.
- or -
2. Is there a concern that during incubation, we might have to be
explicit in communication and always say "Apache Etch" rather than just
"Etch" because of a fear that a reference to "Etch", taken out of
context, could be confused with Debian 4.0?
If "1" is true then, absolutely the name should be changed.
But if only "2" is true, then I will need a bit more convincing. I am
after all very, very lazy and changing the name of a working toolset is
well... work :-)
---
James Dixson
Manager, Software Development
CUAE Engineering, Cisco Systems Inc.
Direct: 512-336-3305
Mobile: 512-968-2116
james.dixson@cisco.com
-----Original Message-----
From: Niklas Gustavsson [mailto:niklas@protocol7.com]
Sent: Tuesday, August 05, 2008 3:33 PM
To: general@incubator.apache.org
Subject: Re: [PROPOSAL] Etch
On Thu, Jul 31, 2008 at 6:16 PM, James Dixson <ja...@cisco.com>
wrote:
> This a proposal to enter Etch in to the incubator.
>
> See http://wiki.apache.org/incubator/EtchProposal for updates.
+1 for incubation (non-binding). While I find this area to be a bit
overcrowded lately, having both Etch and Thrift at Apache and Protocol
buffers under ASL 2.0 does offer some interesting opportunities for
competition as well as cooperation.
I do share the concerns about naming conflicts. Debian is by far more
well known and trying to establish this project under a conflicting
name would be hard.
/niklas
---------------------------------------------------------------------
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: [PROPOSAL] Etch
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Thu, Jul 31, 2008 at 6:16 PM, James Dixson <ja...@cisco.com> wrote:
> This a proposal to enter Etch in to the incubator.
>
> See http://wiki.apache.org/incubator/EtchProposal for updates.
+1 for incubation (non-binding). While I find this area to be a bit
overcrowded lately, having both Etch and Thrift at Apache and Protocol
buffers under ASL 2.0 does offer some interesting opportunities for
competition as well as cooperation.
I do share the concerns about naming conflicts. Debian is by far more
well known and trying to establish this project under a conflicting
name would be hard.
/niklas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org