Re: [PROPOSAL] Tashi
On Wed, 2008-07-23 at 11:10 -0700, Doug Cutting wrote: > Henning Schmiedehausen wrote: [...] Hi Doug, I noticed that you cut out the part about interfacing with Apache-incompatible code. As this project will be surrounded on all sides by non-Apache license able code, do you have a plan on how to amend this and how does the current demo code handle this? Ciao Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | JEE, Linux, Unix 91054 Buckenhof, Germany -- +49 9131 506540 | Apache Java Software Open Source Consulting, Development, Design| INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 Gesellschaftssitz: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen char name_buf[257]; /* max unix filename is 256, right? */ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Tashi
Hello, I've also been closely following the messages exchanged about the Tashi project proposal and I too, like Michael Stroucken, would like to respond to them. I'm the other initial committer listed on the project proposal, Michael Ryan. I am a software engineer at Intel and I have my own motivations for working on Tashi, as well as the blessing of my employer. Some of the pieces of software I write at Intel (scientific apps, performance studies, hardware simulations, etc.) are used on a cluster we have built at our site in Pittsburgh. Since we are a small site, I have ended up doing much of the cluster management myself. Part of this management has included rolling our own cluster management software that uses a bunch PXE boot options, a database, and a bunch of poorly written scripts. As the cluster has grown, however, it has turned into a true multi-user cluster and I am consistently surprised at the new and unique ways users find to break things in the cluster. For me, this project is about finding a way to manage this resource. It's about taking our current ad-hoc cluster management to the next level by involving others with similar problems/interests. It is true that many of the other names listed on the proposal are researchers and are looking to get research publications out of this. However, the two initial committers have a vested interest in seeing a functional and maintained piece of software that will be useful for them. In all honesty, I'd like to see Tashi working so that I can spend less time being a cluster admin and more time being a software engineer. - Michael Ryan -Original Message- From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 23, 2008 5:23 PM To: general@incubator.apache.org Subject: Re: [PROPOSAL] Tashi Doug Cutting wrote: > > There's no conspiracy here to steal Apacheness. Rather, Yahoo!, Intel > and CMU would like to collaborate on open source software. Intel and > CMU have a prototype, and Yahoo! is interested in helping to develop > this further. All three believe that other parties will also be > interested in this software. Apache is a good home for collaborative, > open-source software projects, no? Here's the gist of the issue, and your email highlights it perfectly. Yahoo!, Intel, CMU etc have no standing at the ASF. The ASF does not recognize collaborative "corporate" development; the ASF recognizes collaborative development by physical persons, not other legal constructs or amalgamation. In other words, I'll vote -1 on any Proposal for non-person entities X, Y, and Z to form an incubator podling, and I know several other PMC members who will do likewise. This looks like a very interesting technology, and when proposed as a collaboration by actual persons A, B, and C (who happen to work for X, Y, and Z) we will have something to discuss. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Tashi
Henning Schmiedehausen wrote: I noticed that you cut out the part about interfacing with Apache-incompatible code. As this project will be surrounded on all sides by non-Apache license able code, do you have a plan on how to amend this and how does the current demo code handle this? I would expect that Tashi would use Xen command-line programs, not link directly to Xen's C API's. And, for software like Tashi, whose primary role is to manage Xen-based clusters, Xen is clearly a "system requirement", and is acceptable under Apache's 3rd party license policy. This seems to me like an issue to be handled in detail during incubation. If we cannot find a workable solution, then Tashi would not graduate, but at this point I don't see obvious IP roadblocks. Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Tashi
Doug Cutting wrote: > There's no conspiracy here to steal Apacheness. Rather, Yahoo!, Intel > and CMU would like to collaborate on open source software. Intel and > CMU have a prototype, and Yahoo! is interested in helping to develop > this further. All three believe that other parties will also be > interested in this software. Apache is a good home for collaborative, > open-source software projects, no? Correct, and I also expect that there should be interest from a variety of other entities. We do want the individuals listed, not companies, but by the same token, I will remind some of the commentors that we do want to have some idea of affiliation. > Several are managers that contributed to the proposal. They control > budgets that will pay contributors. Should they remove their names? IMO, yes. They are not Committers. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Tashi
Doug Cutting wrote: > I would expect that Tashi would use Xen command-line programs, not link > directly to Xen's C API's. Why? Personally, I hope that you are wrong. I would expect Tashi to define a vendor neutral layer to which Xen, VMware, KVM, etc., implementations could be written. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Tashi
Henning Schmiedehausen wrote: > The wording for the Yahoo! "slot" sounded to me like there has been a > decision at management level that CMU, Intel and Yahoo! want to do some > work on that subject [...] I believe that we've made it clear that there are no corporate slots, and that the language needed reworking. > And finally: from your proposal and your concept, it is very clear to > me that you *will* be cutting very very close to proprietary open source > (i.e. GPL licensed) code and you will need to interface with such code. > XEN e.g. is GPLv2 licensed and you can not host any code at Apache that > needs to be linked with XEN. Now that raises an interesting question ... if we define our own vendor neutral, Apache licensed, interface definition, are we allowed to host the source for our own implementation of it that is intended to support a GPL licensed work? I have my view on that, but it is an interesting issue. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Tashi
On Thu, 2008-07-24 at 19:22 -0400, Noel J. Bergman wrote: > Henning Schmiedehausen wrote: > > > XEN e.g. is GPLv2 licensed and you can not host any code at Apache that > > needs to be linked with XEN. > > Now that raises an interesting question ... if we define our own vendor > neutral, Apache licensed, interface definition, are we allowed to host the > source for our own implementation of it that is intended to support a GPL > licensed work? I have my view on that, but it is an interesting issue. That question has IMHO already been answered, as we host the reference implementations to various JSRs for which other-licensed implementations exist. So yes, we can host this, if we define the layer or have the layer definition under Apache license. To be clear: I don't want to be a road block here, I just like to have these questions discussed before incubation begins; nothing is worse than having Tashi in incubation for a few months, having them started a community at Apache and then finding out that there are showstoppers that makes it impossible to continue here. Better get this resolved before we start. Ciao Henning - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Tashi
Henning Schmiedehausen wrote: > On Thu, 2008-07-24 at 19:22 -0400, Noel J. Bergman wrote: > > Now that raises an interesting question ... if we define our own vendor > > neutral, Apache licensed, interface definition, are we allowed to host the > > source for our own implementation of it that is intended to support a GPL > > licensed work? I have my view on that, but it is an interesting issue. > > That question has IMHO already been answered, as we host the reference > implementations to various JSRs for which other-licensed implementations > exist. So yes, we can host this, if we define the layer or have the > layer definition under Apache license. > > To be clear: I don't want to be a road block here, I just like to have > these questions discussed before incubation begins; nothing is worse > than having Tashi in incubation for a few months, having them started a > community at Apache and then finding out that there are showstoppers > that makes it impossible to continue here. Better get this resolved > before we start. I would like to provide some concrete information for this discussion. The current implementation defines an interface for manipulating VMs. Using this interface, we've written two VM controllers, one for Xen using command line programs and one for Qemu/KVM using its monitor. We did this because we were concerned about potential licensing issues that may arise if we were to use a C API (with a dynamic library). Am I to understand from this thread that it would somehow be okay to use Xen's C API? If so, can someone be more explicit about what the limitations are? - Michael Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Tashi
Noel J. Bergman wrote: Doug Cutting wrote: I would expect that Tashi would use Xen command-line programs, not link directly to Xen's C API's. Why? Mostly because I don't know what I'm talking about, and I don't think we need to resolve this at this point on this list and I'm trying to make a glib answer to calm folks down a bit. Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Tashi
Henning Schmiedehausen wrote: To be clear: I don't want to be a road block here, I just like to have these questions discussed before incubation begins; nothing is worse than having Tashi in incubation for a few months, having them started a community at Apache and then finding out that there are showstoppers that makes it impossible to continue here. Better get this resolved before we start. Tashi's mentors are well aware of Apache's 3rd party licensing guidelines, as described at: http://www.apache.org/legal/3party.html Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
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 , I discussed and reviewed it with 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
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 , I discussed and reviewed > it with 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
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" <[EMAIL PROTECTED]> 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) [EMAIL PROTECTED] (p) 512-336-3305 (m) 512-968-2116 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
On Thu, Jul 31, 2008 at 12:16 PM, James Dixson <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
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" <[EMAIL PROTECTED]> 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) [EMAIL PROTECTED] (p) 512-336-3305 (m) 512-968-2116 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
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" <[EMAIL PROTECTED]> 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 , I discussed and reviewed > it with 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- James Dixson Manager, Software Development CUAE Engineering, Cisco Systems (e) [EMAIL PROTECTED] (p) 512-336-3305 (m) 512-968-2116 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
On Fri, Aug 1, 2008 at 5:41 AM, Upayavira <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
Niclas Hedhman <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
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" <[EMAIL PROTECTED]> wrote: > On Fri, Aug 1, 2008 at 5:41 AM, Upayavira <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- James Dixson Manager, Software Development CUAE Engineering, Cisco Systems (e) [EMAIL PROTECTED] (p) 512-336-3305 (m) 512-968-2116 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
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 <[EMAIL PROTECTED]> 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 netw
Re: [PROPOSAL] Etch
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
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" <[EMAIL PROTECTED]> wrote: On Fri, Aug 1, 2008 at 5:41 AM, Upayavira <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 tha
Re: [PROPOSAL] Etch
Yes that was the paragraph I was referring to. Paul On Fri, Aug 1, 2008 at 9:29 PM, James Dixson <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 be
Re: [PROPOSAL] Etch
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
Thank you for the support Yonik! -- james On 8/4/08 3:00 PM, "Yonik Seeley" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- James Dixson Manager, Software Development CUAE Engineering, Cisco Systems (e) [EMAIL PROTECTED] (p) 512-336-3305 (m) 512-968-2116 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
On Fri, Aug 1, 2008 at 2:23 PM, scott comer (sccomer) <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
On 8/1/08, scott comer (sccomer) <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
On Thu, Jul 31, 2008 at 6:16 PM, James Dixson <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Etch
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 [EMAIL PROTECTED] -Original Message- From: Niklas Gustavsson [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
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 [EMAIL PROTECTED] -Original Message- From: Niklas Gustavsson [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
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 <[EMAIL PROTECTED]> wrote: > On Thu, Jul 31, 2008 at 6:16 PM, James Dixson <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
Thanks for the support Paul! -- james On 8/6/08 4:58 AM, "Paul Fremantle" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > wrote: >> On Thu, Jul 31, 2008 at 6:16 PM, James Dixson <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- James Dixson Manager, Software Development CUAE Engineering, Cisco Systems (e) [EMAIL PROTECTED] (p) 512-336-3305 (m) 512-968-2116 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
Doug Cutting has a few nice and short naming rules that I liked when I read them. I believe one of them was that a Google search for the proposed name should yield very few matches. Hadoop and Lucene are/were good examples of that. Here is another naming example. I created this bookmarking service called "simpy" - simpy.com . Great name - short, memorable, easy to spell, etc. people said. The problem with it is that "simpy" is a common misspelling of "simply". So, another thing to keep in mind. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message > From: James Dixson (jadixson) <[EMAIL PROTECTED]> > To: general@incubator.apache.org > Sent: Tuesday, August 5, 2008 6:03:28 PM > Subject: RE: [PROPOSAL] Etch > > 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 > [EMAIL PROTECTED] > > -Original Message- > From: Niklas Gustavsson [mailto:[EMAIL PROTECTED] > 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 > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: [PROPOSAL] Etch
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
On Wed, Aug 6, 2008 at 10:20 PM, Niclas Hedhman <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
On Thu, Aug 7, 2008 at 12:10 AM, Niclas Hedhman <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
Yonik Seeley wrote: On Thu, Aug 7, 2008 at 12:10 AM, Niclas Hedhman <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] with your request to become a PMC member, and Noel will relay this to the board. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
Folks, Can I ask if anyone has compared Etch with Apache Tuscany and the SCA specifications? Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
Doug is a wise man and that is how we picked the name etch 18 month ago. Scott out -Original Message- From: Otis Gospodnetic [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 12:12 PM Pacific Standard Time To: general@incubator.apache.org Subject:Re: [PROPOSAL] Etch Doug Cutting has a few nice and short naming rules that I liked when I read them. I believe one of them was that a Google search for the proposed name should yield very few matches. Hadoop and Lucene are/were good examples of that. Here is another naming example. I created this bookmarking service called "simpy" - simpy.com . Great name - short, memorable, easy to spell, etc. people said. The problem with it is that "simpy" is a common misspelling of "simply". So, another thing to keep in mind. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message > From: James Dixson (jadixson) <[EMAIL PROTECTED]> > To: general@incubator.apache.org > Sent: Tuesday, August 5, 2008 6:03:28 PM > Subject: RE: [PROPOSAL] Etch > > 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 > [EMAIL PROTECTED] > > -Original Message- > From: Niklas Gustavsson [mailto:[EMAIL PROTECTED] > 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 > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
Hey, I was apple's rep to the omg for awhile and a member of the persistent comittee. As the etch architect, that experience has informed my every move. Keep it simple, make it fast. Scott out >From the monterey bay aquarium -Original Message- From: Craig L Russell [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 12:41 PM Pacific Standard Time To: general@incubator.apache.org Subject: Re: [PROPOSAL] Etch 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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Re: [PROPOSAL] Etch
http://www.google.com/search?&q=etch -- 12MM hits for an unreleased product (this Etch) http://www.google.com/search?&q=hadoop -- < 600K hits for a product that's been out for over a year Why such resistance to name change? There is this proverb that might be suitable here. The loose translation is: When one person tells you you are a donkey, ignore him. When two people tell you you are a donkey, go buy yourself a saddle." Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message > From: Scott Comer (sccomer) <[EMAIL PROTECTED]> > To: general@incubator.apache.org; general@incubator.apache.org > Sent: Thursday, August 7, 2008 2:50:37 PM > Subject: Re: [PROPOSAL] Etch > > Doug is a wise man and that is how we picked the name etch 18 month ago. > > Scott out > > > > > > -Original Message- > From: Otis Gospodnetic [mailto:[EMAIL PROTECTED] > Sent:Wednesday, August 06, 2008 12:12 PM Pacific Standard Time > To:general@incubator.apache.org > Subject:Re: [PROPOSAL] Etch > > Doug Cutting has a few nice and short naming rules that I liked when I read > them. I believe one of them was that a Google search for the proposed name > should yield very few matches. Hadoop and Lucene are/were good examples of > that. Here is another naming example. I created this bookmarking service > called "simpy" - simpy.com . Great name - short, memorable, easy to spell, > etc. > people said. The problem with it is that "simpy" is a common misspelling of > "simply". So, another thing to keep in mind. > > > Otis > -- > Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch > > > > - Original Message > > From: James Dixson (jadixson) > > To: general@incubator.apache.org > > Sent: Tuesday, August 5, 2008 6:03:28 PM > > Subject: RE: [PROPOSAL] Etch > > > > 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 > > [EMAIL PROTECTED] > > > > -Original Message- > > From: Niklas Gustavsson [mailto:[EMAIL PROTECTED] > > 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 > > 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 woul
RE: [PROPOSAL] Etch
Simple put: a name change is work. Before I can accept the need to do work, I want to clearly understand the benefits of doing it. Etch, while new to open-source, does have some awareness in a technical community ( http://developer.cisco.com/web/cuae ). We have been publicly pitching and distributing etch in our community for several months now. People have been using the technology and for our current community Etch != Debian. Granted, a couple of months is a short amount of time, but it is something. Imposing a name change on our current community, with the reasoning that the future community, would be unable to differentiate between "Apache Etch" and the etch release Debian, would be disruptive. So I am reluctant to change the name, because 'Etch' is a name that has meaning and association with the community into which we have introduced it. I am willing to support a name change, I really am. I just need a stronger argument than 'some people may be confused'. It does not track with my current experience. Are there examples from pass incubations where a name was changed upon acceptance even though there was a community/history behind the name beforehand? --- James -Original Message- From: Otis Gospodnetic [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2008 11:16 PM To: general@incubator.apache.org Subject: Re: [PROPOSAL] Etch http://www.google.com/search?&q=etch -- 12MM hits for an unreleased product (this Etch) http://www.google.com/search?&q=hadoop -- < 600K hits for a product that's been out for over a year Why such resistance to name change? There is this proverb that might be suitable here. The loose translation is: When one person tells you you are a donkey, ignore him. When two people tell you you are a donkey, go buy yourself a saddle." Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message > From: Scott Comer (sccomer) <[EMAIL PROTECTED]> > To: general@incubator.apache.org; general@incubator.apache.org > Sent: Thursday, August 7, 2008 2:50:37 PM > Subject: Re: [PROPOSAL] Etch > > Doug is a wise man and that is how we picked the name etch 18 month ago. > > Scott out > > > > > > -Original Message- > From: Otis Gospodnetic [mailto:[EMAIL PROTECTED] > Sent:Wednesday, August 06, 2008 12:12 PM Pacific Standard Time > To:general@incubator.apache.org > Subject:Re: [PROPOSAL] Etch > > Doug Cutting has a few nice and short naming rules that I liked when I read > them. I believe one of them was that a Google search for the proposed name > should yield very few matches. Hadoop and Lucene are/were good examples of > that. Here is another naming example. I created this bookmarking service > called "simpy" - simpy.com . Great name - short, memorable, easy to spell, etc. > people said. The problem with it is that "simpy" is a common misspelling of > "simply". So, another thing to keep in mind. > > > Otis > -- > Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch > > > > - Original Message > > From: James Dixson (jadixson) > > To: general@incubator.apache.org > > Sent: Tuesday, August 5, 2008 6:03:28 PM > > Subject: RE: [PROPOSAL] Etch > > > > 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. > > > >
Re: [PROPOSAL] Etch
On Aug 8, 2008, at 4:28 AM, James Dixson (jadixson) wrote: Simple put: a name change is work. Before I can accept the need to do work, I want to clearly understand the benefits of doing it. Etch, while new to open-source, does have some awareness in a technical community ( http://developer.cisco.com/web/cuae ). We have been publicly pitching and distributing etch in our community for several months now. People have been using the technology and for our current community Etch != Debian. Granted, a couple of months is a short amount of time, but it is something. Imposing a name change on our current community, with the reasoning that the future community, would be unable to differentiate between "Apache Etch" and the etch release Debian, would be disruptive. I don't think the argument is necessarily that the future community can't distinguish between Apache Etch and Debian, I think the argument is that the future community won't be able to find it, period, which means the future community may well be smaller than it would be w/ a more distinctive name. Put it this way, you search for Hadoop, the top 10 on Google is all Apache Hadoop. You search for Etch and you will be lucky to crack the top 10, me thinks, but who knows maybe you'll get enough rank to displace the Etch-a-Sketch and it will be a non-issue. Of course, the work thing I understand, too, although it seems like a global search and replace wouldn't be that bad. You also certainly could change it over time, even after being accepted into incubation, I think, just as long as it's done before first release. FWIW, I like the name Etch :-) -Grant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
Grant is right. Others were making the point about Debian. I was making a point about it being an overly generic English word. The former may be a short term problem, the latter a very long term one. If changing the name is such a problem (work) then... Otis P.S. I, too, like the name Etch, it's just that it's an English word, plus there are several other products with "Etch" in their name. - Original Message > From: Grant Ingersoll <[EMAIL PROTECTED]> > To: general@incubator.apache.org > Sent: Friday, August 8, 2008 6:28:23 AM > Subject: Re: [PROPOSAL] Etch > > > On Aug 8, 2008, at 4:28 AM, James Dixson (jadixson) wrote: > > > Simple put: a name change is work. Before I can accept the need to do > > work, I want to clearly understand the benefits of doing it. > > > > Etch, while new to open-source, does have some awareness in a > > technical > > community ( http://developer.cisco.com/web/cuae ). We have been > > publicly > > pitching and distributing etch in our community for several months > > now. > > People have been using the technology and for our current community > > Etch > > != Debian. Granted, a couple of months is a short amount of time, > > but it > > is something. Imposing a name change on our current community, with > > the > > reasoning that the future community, would be unable to differentiate > > between "Apache Etch" and the etch release Debian, would be > > disruptive. > > I don't think the argument is necessarily that the future community > can't distinguish between Apache Etch and Debian, I think the argument > is that the future community won't be able to find it, period, which > means the future community may well be smaller than it would be w/ a > more distinctive name. > > Put it this way, you search for Hadoop, the top 10 on Google is all > Apache Hadoop. You search for Etch and you will be lucky to crack the > top 10, me thinks, but who knows maybe you'll get enough rank to > displace the Etch-a-Sketch and it will be a non-issue. > > Of course, the work thing I understand, too, although it seems like a > global search and replace wouldn't be that bad. You also certainly > could change it over time, even after being accepted into incubation, > I think, just as long as it's done before first release. > > FWIW, I like the name Etch :-) > > -Grant > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
On Fri, Aug 1, 2008 at 8:23 PM, scott comer (sccomer) <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
as a scientist, i am getting somewhat bristly at all the rumor, innuendo, and hyperbole around names. i've not seen any definitive or measurable steps that can be take to ensure success. we're also ignoring the silent majority which seems to like etch just fine. my personal opinion is that the name is not the gating factor for success. apache pig? really. success and web hits will derive from being truly useful and trusted. it doesn't work the other way around. simply dictionary word names and result counts on google certainly don't count. several apache projects are named with dictionary words with significantly larger search result counts than etch. to state the obvious, what counts is that people can find you. i've seen studies and information on how to try to game google's system. many of them contradict each other, but everyone can agree that you better be on the first page and with something clearly definitive near the top of the first screen. from their info, two things matter: 1) links from various "definitive" sources to the etch page. this can come from links from reviews, cisco.com, java.sun.com, apache home page, microsoft csharp page, python, ruby, wikipedia, about.com, etc. these things are not present now, but will be shortly if we could get past this. 2) names must be memorable enough so that a casual reference in a conversation can be turned into a successful search later. examples of this might be "etch", "etch protocol", "etch java", etc. if you search for "etch service description language" or "etch protocol" right now you get to the right place. nothing is more off-putting than a name which you cannot spell having only heard it. word combinations are also out for the same reason, because people enter them as two separate words. finally, if your name is intentionally misspelled, watch out. google will suggest a better spelling and people often automatically take its advice. the important thing right now is, i think, that searching now for etch doesn't not reveal anything which is obviously competing technology (east tennessee children's hospital is #1, debian #2, etch a sketch #3). nothing obviously confusing comes up. therefore, plenty of room for etch to elbow its way to the #1 spot, esp when combined with other keywords. when choosing the name etch, we thought it important to choose a short word which wasn't already a tech name. it needed to connote writing and communication. it need to be easy to remember, etc. i really like the name etch, obviously, it is short and memorable and mnemonic, i haven't seen anything which would indicate that a successful and useful technology would not be adopted just because of its name. changing the name now seems fussy and would muddy water enough to confuse the small toe hold we already have (cio.com article, cisco video presentations, existing cisco customers, etc.). it isn't worth it right now without definitive proof that the new name is better. let's hear from the silent majority! scott out Grant Ingersoll wrote: On Aug 8, 2008, at 4:28 AM, James Dixson (jadixson) wrote: Simple put: a name change is work. Before I can accept the need to do work, I want to clearly understand the benefits of doing it. Etch, while new to open-source, does have some awareness in a technical community ( http://developer.cisco.com/web/cuae ). We have been publicly pitching and distributing etch in our community for several months now. People have been using the technology and for our current community Etch != Debian. Granted, a couple of months is a short amount of time, but it is something. Imposing a name change on our current community, with the reasoning that the future community, would be unable to differentiate between "Apache Etch" and the etch release Debian, would be disruptive. I don't think the argument is necessarily that the future community can't distinguish between Apache Etch and Debian, I think the argument is that the future community won't be able to find it, period, which means the future community may well be smaller than it would be w/ a more distinctive name. Put it this way, you search for Hadoop, the top 10 on Google is all Apache Hadoop. You search for Etch and you will be lucky to crack the top 10, me thinks, but who knows maybe you'll get enough rank to displace the Etch-a-Sketch and it will be a non-issue. Of course, the work thing I understand, too, although it seems like a global search and replace wouldn't be that bad. You also certainly could change it over time, even after being accepted into incubation, I think, just as long as it's done before first release. FWIW, I like the name Etch :-) -Grant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail:
Re: [PROPOSAL] Etch
+1 Well said. Part of the silent majority, Craig On Aug 12, 2008, at 10:29 AM, scott comer wrote: as a scientist, i am getting somewhat bristly at all the rumor, innuendo, and hyperbole around names. i've not seen any definitive or measurable steps that can be take to ensure success. we're also ignoring the silent majority which seems to like etch just fine. my personal opinion is that the name is not the gating factor for success. apache pig? really. success and web hits will derive from being truly useful and trusted. it doesn't work the other way around. simply dictionary word names and result counts on google certainly don't count. several apache projects are named with dictionary words with significantly larger search result counts than etch. to state the obvious, what counts is that people can find you. i've seen studies and information on how to try to game google's system. many of them contradict each other, but everyone can agree that you better be on the first page and with something clearly definitive near the top of the first screen. from their info, two things matter: 1) links from various "definitive" sources to the etch page. this can come from links from reviews, cisco.com, java.sun.com, apache home page, microsoft csharp page, python, ruby, wikipedia, about.com, etc. these things are not present now, but will be shortly if we could get past this. 2) names must be memorable enough so that a casual reference in a conversation can be turned into a successful search later. examples of this might be "etch", "etch protocol", "etch java", etc. if you search for "etch service description language" or "etch protocol" right now you get to the right place. nothing is more off-putting than a name which you cannot spell having only heard it. word combinations are also out for the same reason, because people enter them as two separate words. finally, if your name is intentionally misspelled, watch out. google will suggest a better spelling and people often automatically take its advice. the important thing right now is, i think, that searching now for etch doesn't not reveal anything which is obviously competing technology (east tennessee children's hospital is #1, debian #2, etch a sketch #3). nothing obviously confusing comes up. therefore, plenty of room for etch to elbow its way to the #1 spot, esp when combined with other keywords. when choosing the name etch, we thought it important to choose a short word which wasn't already a tech name. it needed to connote writing and communication. it need to be easy to remember, etc. i really like the name etch, obviously, it is short and memorable and mnemonic, i haven't seen anything which would indicate that a successful and useful technology would not be adopted just because of its name. changing the name now seems fussy and would muddy water enough to confuse the small toe hold we already have (cio.com article, cisco video presentations, existing cisco customers, etc.). it isn't worth it right now without definitive proof that the new name is better. let's hear from the silent majority! scott out Grant Ingersoll wrote: On Aug 8, 2008, at 4:28 AM, James Dixson (jadixson) wrote: Simple put: a name change is work. Before I can accept the need to do work, I want to clearly understand the benefits of doing it. Etch, while new to open-source, does have some awareness in a technical community ( http://developer.cisco.com/web/cuae ). We have been publicly pitching and distributing etch in our community for several months now. People have been using the technology and for our current community Etch != Debian. Granted, a couple of months is a short amount of time, but it is something. Imposing a name change on our current community, with the reasoning that the future community, would be unable to differentiate between "Apache Etch" and the etch release Debian, would be disruptive. I don't think the argument is necessarily that the future community can't distinguish between Apache Etch and Debian, I think the argument is that the future community won't be able to find it, period, which means the future community may well be smaller than it would be w/ a more distinctive name. Put it this way, you search for Hadoop, the top 10 on Google is all Apache Hadoop. You search for Etch and you will be lucky to crack the top 10, me thinks, but who knows maybe you'll get enough rank to displace the Etch-a-Sketch and it will be a non-issue. Of course, the work thing I understand, too, although it seems like a global search and replace wouldn't be that bad. You also certainly could change it over time, even after being accepted into incubation, I think, just as long as it's done before first release. FWIW, I like the name Etch :-) -Grant - To unsubscribe, e-ma
Re: [PROPOSAL] Etch
+1 to Scott's comments. I don't think the name is a significant conflict at all. Debian Etch is a release codename - regular references to it will fade away as the next release surfaces, and the Apache Etch name, if it is a successful project, should last much longer. This would supplant recognition over time, so it is not a big deal to keep the Etch name IMO. Majorly silent, Les On Tue, Aug 12, 2008 at 2:06 PM, Craig L Russell <[EMAIL PROTECTED]>wrote: > +1 Well said. > > Part of the silent majority, > > Craig > > > On Aug 12, 2008, at 10:29 AM, scott comer wrote: > > as a scientist, i am getting somewhat bristly at all the rumor, innuendo, >> and hyperbole around names. i've not seen any definitive or measurable steps >> that can be take to ensure success. we're also ignoring the silent majority >> which seems to like etch just fine. my personal opinion is that the name is >> not the gating factor for success. apache pig? really. success and web hits >> will derive from being truly useful and trusted. it doesn't work the other >> way around. >> >> simply dictionary word names and result counts on google certainly don't >> count. several apache projects are named with dictionary words with >> significantly larger search result counts than etch. >> >> to state the obvious, what counts is that people can find you. i've seen >> studies and information on how to try to game google's system. many of them >> contradict each other, but everyone can agree that you better be on the >> first page and with something clearly definitive near the top of the first >> screen. from their info, two things matter: >> >> 1) links from various "definitive" sources to the etch page. this can come >> from links from reviews, cisco.com, java.sun.com, apache home page, >> microsoft csharp page, python, ruby, wikipedia, about.com, etc. these >> things are not present now, but will be shortly if we could get past this. >> >> 2) names must be memorable enough so that a casual reference in a >> conversation can be turned into a successful search later. examples of this >> might be "etch", "etch protocol", "etch java", etc. if you search for "etch >> service description language" or "etch protocol" right now you get to the >> right place. nothing is more off-putting than a name which you cannot spell >> having only heard it. word combinations are also out for the same reason, >> because people enter them as two separate words. finally, if your name is >> intentionally misspelled, watch out. google will suggest a better spelling >> and people often automatically take its advice. >> >> the important thing right now is, i think, that searching now for etch >> doesn't not reveal anything which is obviously competing technology (east >> tennessee children's hospital is #1, debian #2, etch a sketch #3). nothing >> obviously confusing comes up. therefore, plenty of room for etch to elbow >> its way to the #1 spot, esp when combined with other keywords. >> >> when choosing the name etch, we thought it important to choose a short >> word which wasn't already a tech name. it needed to connote writing and >> communication. it need to be easy to remember, etc. >> >> i really like the name etch, obviously, it is short and memorable and >> mnemonic, i haven't seen anything which would indicate that a successful and >> useful technology would not be adopted just because of its name. changing >> the name now seems fussy and would muddy water enough to confuse the small >> toe hold we already have (cio.com article, cisco video presentations, >> existing cisco customers, etc.). it isn't worth it right now without >> definitive proof that the new name is better. >> >> let's hear from the silent majority! >> >> scott out >> >> Grant Ingersoll wrote: >> >>> On Aug 8, 2008, at 4:28 AM, James Dixson (jadixson) wrote: >>> >>> Simple put: a name change is work. Before I can accept the need to do work, I want to clearly understand the benefits of doing it. Etch, while new to open-source, does have some awareness in a technical community ( http://developer.cisco.com/web/cuae ). We have been publicly pitching and distributing etch in our community for several months now. People have been using the technology and for our current community Etch != Debian. Granted, a couple of months is a short amount of time, but it is something. Imposing a name change on our current community, with the reasoning that the future community, would be unable to differentiate between "Apache Etch" and the etch release Debian, would be disruptive. >>> >>> I don't think the argument is necessarily that the future community can't >>> distinguish between Apache Etch and Debian, I think the argument is that the >>> future community won't be able to find it, period, which means the future >>> community may well be smaller than it would be w/ a more distinctive name. >>> >>> Put it this way, you search for Hadoop, the top
RE: [PROPOSAL] Etch
Scott Comer wrote: > as a scientist, i am getting somewhat bristly at all the rumor, > innuendo, and hyperbole around names. Can you be more specific? So far the best argument against Etch that I've seen is Grant's, and Les makes a good point about the transient nature of such release labels. > the important thing right now is, i think, that searching now for etch > doesn't not reveal anything which is obviously competing technology True, but were the debian community to make "a federal case" of the issue, I don't know that the name would be worth the conflict, even if we'd be in the legal clear. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
On Tue, Aug 12, 2008 at 6:29 PM, scott comer <[EMAIL PROTECTED]> wrote: > as a scientist, i am getting somewhat bristly at all the rumor, innuendo, > and hyperbole around names. i've not seen any definitive or measurable steps > that can be take to ensure success. we're also ignoring the silent majority > which seems to like etch just fine. my personal opinion is that the name is > not the gating factor for success. apache pig? really. success and web hits > will derive from being truly useful and trusted. it doesn't work the other > way around. > > simply dictionary word names and result counts on google certainly don't > count. several apache projects are named with dictionary words with > significantly larger search result counts than etch. > > to state the obvious, what counts is that people can find you. i've seen > studies and information on how to try to game google's system. many of them > contradict each other, but everyone can agree that you better be on the > first page and with something clearly definitive near the top of the first > screen. from their info, two things matter: > > 1) links from various "definitive" sources to the etch page. this can come > from links from reviews, cisco.com, java.sun.com, apache home page, > microsoft csharp page, python, ruby, wikipedia, about.com, etc. these things > are not present now, but will be shortly if we could get past this. > > 2) names must be memorable enough so that a casual reference in a > conversation can be turned into a successful search later. examples of this > might be "etch", "etch protocol", "etch java", etc. if you search for "etch > service description language" or "etch protocol" right now you get to the > right place. nothing is more off-putting than a name which you cannot spell > having only heard it. word combinations are also out for the same reason, > because people enter them as two separate words. finally, if your name is > intentionally misspelled, watch out. google will suggest a better spelling > and people often automatically take its advice. > > the important thing right now is, i think, that searching now for etch > doesn't not reveal anything which is obviously competing technology (east > tennessee children's hospital is #1, debian #2, etch a sketch #3). nothing > obviously confusing comes up. therefore, plenty of room for etch to elbow > its way to the #1 spot, esp when combined with other keywords. > > when choosing the name etch, we thought it important to choose a short word > which wasn't already a tech name. it needed to connote writing and > communication. it need to be easy to remember, etc. > > i really like the name etch, obviously, it is short and memorable and > mnemonic, i haven't seen anything which would indicate that a successful and > useful technology would not be adopted just because of its name. changing > the name now seems fussy and would muddy water enough to confuse the small > toe hold we already have (cio.com article, cisco video presentations, > existing cisco customers, etc.). it isn't worth it right now without > definitive proof that the new name is better. > > let's hear from the silent majority! Theres nothing wrong with people suggesting/commenting/questioning names and its better to raise it now than later and I don't think its worth getting worked up about - there is something worse than feedback you don't like - complete indifference to a proposal. Having said that, unless there are valid objections to a name (and I don't see any for Etch) then it should be up to the podling community to decide what they call themselves. So I'm mostly +1 to what you said (just not the bristly bit!) Niall > scott out > > Grant Ingersoll wrote: >> >> On Aug 8, 2008, at 4:28 AM, James Dixson (jadixson) wrote: >> >>> Simple put: a name change is work. Before I can accept the need to do >>> work, I want to clearly understand the benefits of doing it. >>> >>> Etch, while new to open-source, does have some awareness in a technical >>> community ( http://developer.cisco.com/web/cuae ). We have been publicly >>> pitching and distributing etch in our community for several months now. >>> People have been using the technology and for our current community Etch >>> != Debian. Granted, a couple of months is a short amount of time, but it >>> is something. Imposing a name change on our current community, with the >>> reasoning that the future community, would be unable to differentiate >>> between "Apache Etch" and the etch release Debian, would be disruptive. >> >> I don't think the argument is necessarily that the future community can't >> distinguish between Apache Etch and Debian, I think the argument is that the >> future community won't be able to find it, period, which means the future >> community may well be smaller than it would be w/ a more distinctive name. >> >> Put it this way, you search for Hadoop, the top 10 on Google is all Apache >> Hadoop. You search for Etch and you will be lucky to cra
Re: [PROPOSAL] Etch
Noel J. Bergman wrote: Scott Comer wrote: the important thing right now is, i think, that searching now for etch doesn't not reveal anything which is obviously competing technology True, but were the debian community to make "a federal case" of the issue, I don't know that the name would be worth the conflict, even if we'd be in the legal clear. However, the Debian Etch != Apache Etch is a strong statement. If more of these emails, for that matter - their Subject: line, clearly spelled out "Apache Etch", I'd think we could have ended the debate by now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Etch
William A. Rowe, Jr. wrote: > Noel J. Bergman wrote: >> Scott Comer wrote: >>> the important thing right now is, i think, that searching now for etch >>> doesn't not reveal anything which is obviously competing technology >> True, but were the debian community to make "a federal case" of the issue, I >> don't know that the name would be worth the conflict, even if we'd be in the >> legal clear. > However, the Debian Etch != Apache Etch is a strong statement. As I said, we might well be in the clear legally, but we'd have to decide if the conflict were worth it for just a name, and that would depend on whether and how vociferously anyone made a stink. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
the discussion about names seems somewhat done. it is easy to get the impression from the volume that there is a demand for name change. in my opinion there isn't. certainly names is a rich topic and the discussion would never die down on it's own because it is so much fun. it's a wonder anything gets done... here is a summary of who's responded to our proposal and an indication of the topic. [EMAIL PROTECTED] +1 [EMAIL PROTECTED] +1 (MENTOR) [EMAIL PROTECTED] +1 (TOOMANY, NAME) [EMAIL PROTECTED] +1 (NAME) [EMAIL PROTECTED] +1 (TOOGOOD, TOOMANY, NAME, MENTOR) [EMAIL PROTECTED] +1 [EMAIL PROTECTED] +1 (TOOMANY, MENTOR) [EMAIL PROTECTED] (TOOMANY) [EMAIL PROTECTED] (NAME) [EMAIL PROTECTED] (QUESTION) [EMAIL PROTECTED] (NAME) [EMAIL PROTECTED] (NAME) [EMAIL PROTECTED] (NAME) [EMAIL PROTECTED] (TOOMANY) [EMAIL PROTECTED] (TOOMANY) [EMAIL PROTECTED] (NAME) of the people that mention name (8), only 3 are voting: henning: concerned about confusion with debian. only says we need to be careful and explicit. niall: wants to see the q resolved. likes the name, sees no real objection. niclas: conflict with debian; only worries about it. of the rest, most like the name etch and seem to be just "tossing the ball around". the main other concern is that of confusion with Debian Etch vs. Apache Etch. There was some discussion about whether etch could get to the top of the google list. so, can we put the name question to bed? it was suggested that the podling could/should decide the issue for itself, later. is there a problem with that? are there any other concerns about the proposal which aren't addressed? scott out
Re: [PROPOSAL] Etch
Scott, I don't think that my question was answered. I want to make it clear: I have no issues with names. Yours, Mike. scott comer wrote: the discussion about names seems somewhat done. it is easy to get the impression from the volume that there is a demand for name change. in my opinion there isn't. certainly names is a rich topic and the discussion would never die down on it's own because it is so much fun. it's a wonder anything gets done... here is a summary of who's responded to our proposal and an indication of the topic. [EMAIL PROTECTED] +1 [EMAIL PROTECTED] +1 (MENTOR) [EMAIL PROTECTED] +1 (TOOMANY, NAME) [EMAIL PROTECTED] +1 (NAME) [EMAIL PROTECTED] +1 (TOOGOOD, TOOMANY, NAME, MENTOR) [EMAIL PROTECTED] +1 [EMAIL PROTECTED] +1 (TOOMANY, MENTOR) [EMAIL PROTECTED] (TOOMANY) [EMAIL PROTECTED] (NAME) [EMAIL PROTECTED] (QUESTION) [EMAIL PROTECTED] (NAME) [EMAIL PROTECTED] (NAME) [EMAIL PROTECTED] (NAME) [EMAIL PROTECTED] (TOOMANY) [EMAIL PROTECTED] (TOOMANY) [EMAIL PROTECTED] (NAME) of the people that mention name (8), only 3 are voting: henning: concerned about confusion with debian. only says we need to be careful and explicit. niall: wants to see the q resolved. likes the name, sees no real objection. niclas: conflict with debian; only worries about it. of the rest, most like the name etch and seem to be just "tossing the ball around". the main other concern is that of confusion with Debian Etch vs. Apache Etch. There was some discussion about whether etch could get to the top of the google list. so, can we put the name question to bed? it was suggested that the podling could/should decide the issue for itself, later. is there a problem with that? are there any other concerns about the proposal which aren't addressed? scott out - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
sorry, mike! in a 3 minute examination of apache tuscany it seems like there are some similar aims and some overlap in capability. both are addressing SOA issues such as protocol independence and implementation independence. both seek to make deploying service oriented architectures a snap. the two approaches are definitely distinct and many important aims of one are not addressed by the other. there is likely some interesting synergy possible down the road. scott out Mike Edwards wrote: Scott, I don't think that my question was answered. I want to make it clear: I have no issues with names. Yours, Mike. scott comer wrote: the discussion about names seems somewhat done. it is easy to get the impression from the volume that there is a demand for name change. in my opinion there isn't. certainly names is a rich topic and the discussion would never die down on it's own because it is so much fun. it's a wonder anything gets done... here is a summary of who's responded to our proposal and an indication of the topic. [EMAIL PROTECTED] +1 [EMAIL PROTECTED] +1 (MENTOR) [EMAIL PROTECTED] +1 (TOOMANY, NAME) [EMAIL PROTECTED] +1 (NAME) [EMAIL PROTECTED] +1 (TOOGOOD, TOOMANY, NAME, MENTOR) [EMAIL PROTECTED] +1 [EMAIL PROTECTED] +1 (TOOMANY, MENTOR) [EMAIL PROTECTED] (TOOMANY) [EMAIL PROTECTED] (NAME) [EMAIL PROTECTED] (QUESTION) [EMAIL PROTECTED] (NAME) [EMAIL PROTECTED] (NAME) [EMAIL PROTECTED] (NAME) [EMAIL PROTECTED] (TOOMANY) [EMAIL PROTECTED] (TOOMANY) [EMAIL PROTECTED] (NAME) of the people that mention name (8), only 3 are voting: henning: concerned about confusion with debian. only says we need to be careful and explicit. niall: wants to see the q resolved. likes the name, sees no real objection. niclas: conflict with debian; only worries about it. of the rest, most like the name etch and seem to be just "tossing the ball around". the main other concern is that of confusion with Debian Etch vs. Apache Etch. There was some discussion about whether etch could get to the top of the google list. so, can we put the name question to bed? it was suggested that the podling could/should decide the issue for itself, later. is there a problem with that? are there any other concerns about the proposal which aren't addressed? scott out - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
On Wed, Aug 13, 2008 at 12:58 PM, scott comer <[EMAIL PROTECTED]> wrote: > of the people that mention name (8), only 3 are voting: This is a discussion thread, not a formal vote for Etch to enter the Incubator. [...] > so, can we put the name question to bed? it was suggested that the podling > could/should > decide the issue for itself, later. is there a problem with that? IMO, if people think the name should change, it's best to get it decided up front before resources (mailing lists, subversion, etc) have been created. -Yonik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
+1 -Yonik On Sat, Aug 9, 2008 at 4:58 AM, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > On Fri, Aug 1, 2008 at 8:23 PM, scott comer (sccomer) <[EMAIL PROTECTED]> > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Etch
scott comer wrote: > in my opinion there isn't [a demand for name change]. certainly > names is a rich topic and the discussion would never die down on > it's own because it is so much fun. it's a wonder anything gets done. You should have been around for the start of Geronimo. :-) > can we put the name question to bed? Probably. It may come back to bite, but if that's the name you want to start with, I don't see a *compelling* reason to say no. We'll see if anyone disagrees. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Windmill
Just out of curiosity, where does this fit in versus, say, Selenium, MaxQ, Canoo WebTest, and others? There's nothing wrong if Windmill does the same stuff - I'm just curious what it can do in comparison. Cheers, Les On Thu, Aug 14, 2008 at 4:32 PM, Mikeal Rogers <[EMAIL PROTECTED]>wrote: > This is a proposal to enter the incubator. > > See http://wiki.apache.org/incubator/WindmillProposal for the most > up-to-date version. > > We look forward to comments and discussion. > > = Abstract = > > The goal of Windmill is to build the best tool for automated testing of > dynamic Web applications across all major browsers. > > = Proposal = > > Windmill provides a full-stack automation solution for dynamic > Web-application testing. > > It accomplishes this by implementing an extensive test API in JavaScript, > and providing an intelligent proxy that can overcome the browser's > same-domain security policy. The test API allows a single test to run on > every major browser across all major operating systems. > > Windmill boasts a wide range of debugging and test-authoring tools that > make test writing, debugging, and editing a more streamlined process. > > = Background = > > Windmill was created at the Open Source Applications Foundation by Mikeal > Rogers and Adam Christian to test the Chandler Server Web UI. It was > announced more broadly at OSCON 2007 and has since enjoyed a wide range of > use and contributions. > > In January 2008, all the full-time, paid contributors from OSAF moved on to > other employment. The project has since retained steady contribution despite > having no full-time, paid contributors. > > In July 2008, we proposed the project move its hosting away from OSAF > because of uncertainty about long term sustainability -- due to OSAF's > transition to a smaller-scale, mostly volunteer structure. > > = Rationale = > > Windmill was created to fulfill a need for a better dynamic Web-application > testing tool after much frustration with existing solutions. We believe it > has accomplished this goal and continues to improve, with ongoing, open > interaction with the community. > > What the project currently lacks is clear direction, leadership, and > process. We believe the project would benefit greatly from Incubator > mentorship, which would allow it to see much wider adoption, and grow a > broader community. > > = Current Status = > > == Meritocracy == > > Since the project's inception, its development has been coordinated through > collaborative decision-making (e.g., "+1 voting") on the mailing list, and > open discussion on IRC. > > == Community == > > Although the list of Core Developers has remained small we've welcomed > outside contributions. Along with a few small but good patches, we've > received some very good bugs and numerous features requests from the > community. Our wiki documentation is being continually improved by our > users. > > We also have a very good reputation of providing support and resolving > problems on IRC (#windmill on irc.freenode.net).A number of our users have > stayed around to help others in need. > > == Core Developers == > > Mikeal Rogers (Most of the Python code) > Adam Christian (Most of the JavaScript code) > > == Alignment == > > Since Windmill was started at OSAF, it has enjoyed contributions from a > variety of paid staff at OSAF. All of those employees are now employed > elsewhere -- below are the ones that are still active. > > * Mikeal Rogers (Mozillla) > * Adam Christian (Slide) > * Matthew Eernisse (Seesmic) > > = Known Risks = > > == Orphaned Products == > > The project has survived the loss of paid contributions and continues to > grow in use, despite a clear lack of leadership (I have only myself to > blame). > > == Inexperience with Open Source == > > All the contributors have a history in open-source development and the > policies of the project were developed with the help of Ted Leung. > > == Reliance on Salaried Developers == > > As of July 2008 one developer is paid part-time for his work on Windmill. > The rest of the contributions are all volunteer at this time. > > == A Excessive Fascination with the Apache Brand == > > One can't ignore the impact the Apache brand has on a project, but what > this project needs isn't branding -- it's the benefit of Incubator > mentorship, direction, leadership, and process. > > = Documentation = > > http://windmill.osafoundation.org/ > > = Initial Source = > > The code is currently hosted on OSAF's Subversion server. > > http://svn.osafoundation.org/windmill/ > > = Source and Intellectual Property Submission Plan = > > We've gotten consent from OSAF to move the project to new location. > > = External Dependencies = > > We have a long list of external Python dependencies. These dependencies are > managed via setuptools and are not distributed with the Windmill product and > as such should not need be a licensing concern. > > = Required Resources = > > == Mailing lists == > > * windmill-commi
Re: [Proposal] Windmill
Of those 3 it's the most like Selenium. As far as I know the "proxy spoof" method was pioneered by Selenium and we've continued to use/evolve that method of "tricking" the browser's same domain security policy. Our implementation of the test API has been very different from selenium as is our proxy <-> javascript communication workflow. Since our initial release we've done a lot of feature work around the recording, debugging, and test editing workflows. We've also done a good amount of work both in the proxy and in the javascript layer to make having a single test move around different target domains remain seamless and transparent. It's been a while since I used Selenium so I can't comment on their current feature list compared to ours, but at the time we decided to write Windmill we were incredibly frustrated with the process of maintaining tests written in Selenium in an environment where the target product changed rapidly. We found that debugging and editing a test after changes to the product to be as difficult as writing the entire test all over again from scratch and have continued to improve windmill around our own use cases as well as user community feedback. I hope that answers your question, this was a fairly high level answer, if you'd like I can go over any of those features/differences in more detail and point you at any code. -Mikeal On Aug 14, 2008, at August 14, 20081:40 PM, Les Hazlewood wrote: Just out of curiosity, where does this fit in versus, say, Selenium, MaxQ, Canoo WebTest, and others? There's nothing wrong if Windmill does the same stuff - I'm just curious what it can do in comparison. Cheers, Les On Thu, Aug 14, 2008 at 4:32 PM, Mikeal Rogers <[EMAIL PROTECTED] >wrote: This is a proposal to enter the incubator. See http://wiki.apache.org/incubator/WindmillProposal for the most up-to-date version. We look forward to comments and discussion. = Abstract = The goal of Windmill is to build the best tool for automated testing of dynamic Web applications across all major browsers. = Proposal = Windmill provides a full-stack automation solution for dynamic Web-application testing. It accomplishes this by implementing an extensive test API in JavaScript, and providing an intelligent proxy that can overcome the browser's same-domain security policy. The test API allows a single test to run on every major browser across all major operating systems. Windmill boasts a wide range of debugging and test-authoring tools that make test writing, debugging, and editing a more streamlined process. = Background = Windmill was created at the Open Source Applications Foundation by Mikeal Rogers and Adam Christian to test the Chandler Server Web UI. It was announced more broadly at OSCON 2007 and has since enjoyed a wide range of use and contributions. In January 2008, all the full-time, paid contributors from OSAF moved on to other employment. The project has since retained steady contribution despite having no full-time, paid contributors. In July 2008, we proposed the project move its hosting away from OSAF because of uncertainty about long term sustainability -- due to OSAF's transition to a smaller-scale, mostly volunteer structure. = Rationale = Windmill was created to fulfill a need for a better dynamic Web- application testing tool after much frustration with existing solutions. We believe it has accomplished this goal and continues to improve, with ongoing, open interaction with the community. What the project currently lacks is clear direction, leadership, and process. We believe the project would benefit greatly from Incubator mentorship, which would allow it to see much wider adoption, and grow a broader community. = Current Status = == Meritocracy == Since the project's inception, its development has been coordinated through collaborative decision-making (e.g., "+1 voting") on the mailing list, and open discussion on IRC. == Community == Although the list of Core Developers has remained small we've welcomed outside contributions. Along with a few small but good patches, we've received some very good bugs and numerous features requests from the community. Our wiki documentation is being continually improved by our users. We also have a very good reputation of providing support and resolving problems on IRC (#windmill on irc.freenode.net).A number of our users have stayed around to help others in need. == Core Developers == Mikeal Rogers (Most of the Python code) Adam Christian (Most of the JavaScript code) == Alignment == Since Windmill was started at OSAF, it has enjoyed contributions from a variety of paid staff at OSAF. All of those employees are now employed elsewhere -- below are the ones that are still active. * Mikeal Rogers (Mozillla) * Adam Christian (Slide) * Matthew Eernisse (Seesmic) = Known Risks = == Orphaned Products == The project
Re: [Proposal] Windmill
Of those 3 it's the most like Selenium. As far as I know the "proxy spoof" method was pioneered by Selenium and we've continued to use/evolve that method of "tricking" the browser's same domain security policy. Our implementation of the test API has been very different from selenium as is our proxy <-> javascript communication workflow. Since our initial release we've done a lot of feature work around the recording, debugging, and test editing workflows. We've also done a good amount of work both in the proxy and in the javascript layer to make having a single test move around different target domains remain seamless and transparent. It's been a while since I used Selenium so I can't comment on their current feature list compared to ours, but at the time we decided to write Windmill we were incredibly frustrated with the process of maintaining tests written in Selenium in an environment where the target product changed rapidly. We found that debugging and editing a test after changes to the product to be as difficult as writing the entire test all over again from scratch and have continued to improve windmill around our own use cases as well as user community feedback. I hope that answers your question, this was a fairly high level answer, if you'd like I can go over any of those features/differences in more detail and point you at any code. -Mikeal On Aug 14, 2008, at August 14, 20081:40 PM, Les Hazlewood wrote: Just out of curiosity, where does this fit in versus, say, Selenium, MaxQ, Canoo WebTest, and others? There's nothing wrong if Windmill does the same stuff - I'm just curious what it can do in comparison. Cheers, Les On Thu, Aug 14, 2008 at 4:32 PM, Mikeal Rogers <[EMAIL PROTECTED] >wrote: This is a proposal to enter the incubator. See http://wiki.apache.org/incubator/WindmillProposal for the most up-to-date version. We look forward to comments and discussion. = Abstract = The goal of Windmill is to build the best tool for automated testing of dynamic Web applications across all major browsers. = Proposal = Windmill provides a full-stack automation solution for dynamic Web-application testing. It accomplishes this by implementing an extensive test API in JavaScript, and providing an intelligent proxy that can overcome the browser's same-domain security policy. The test API allows a single test to run on every major browser across all major operating systems. Windmill boasts a wide range of debugging and test-authoring tools that make test writing, debugging, and editing a more streamlined process. = Background = Windmill was created at the Open Source Applications Foundation by Mikeal Rogers and Adam Christian to test the Chandler Server Web UI. It was announced more broadly at OSCON 2007 and has since enjoyed a wide range of use and contributions. In January 2008, all the full-time, paid contributors from OSAF moved on to other employment. The project has since retained steady contribution despite having no full-time, paid contributors. In July 2008, we proposed the project move its hosting away from OSAF because of uncertainty about long term sustainability -- due to OSAF's transition to a smaller-scale, mostly volunteer structure. = Rationale = Windmill was created to fulfill a need for a better dynamic Web- application testing tool after much frustration with existing solutions. We believe it has accomplished this goal and continues to improve, with ongoing, open interaction with the community. What the project currently lacks is clear direction, leadership, and process. We believe the project would benefit greatly from Incubator mentorship, which would allow it to see much wider adoption, and grow a broader community. = Current Status = == Meritocracy == Since the project's inception, its development has been coordinated through collaborative decision-making (e.g., "+1 voting") on the mailing list, and open discussion on IRC. == Community == Although the list of Core Developers has remained small we've welcomed outside contributions. Along with a few small but good patches, we've received some very good bugs and numerous features requests from the community. Our wiki documentation is being continually improved by our users. We also have a very good reputation of providing support and resolving problems on IRC (#windmill on irc.freenode.net).A number of our users have stayed around to help others in need. == Core Developers == Mikeal Rogers (Most of the Python code) Adam Christian (Most of the JavaScript code) == Alignment == Since Windmill was started at OSAF, it has enjoyed contributions from a variety of paid staff at OSAF. All of those employees are now employed elsewhere -- below are the ones that are still active. * Mikeal Rogers (Mozillla) * Adam Christian (Slide) * Matthew Eernisse (Seesmic) = Known Risks = == Orphaned Products == The project
Re: [PROPOSAL] Etch
FWIW, I'm +1 on the proposal, regardless of the name. On Aug 13, 2008, at 12:58 PM, scott comer wrote: the discussion about names seems somewhat done. it is easy to get the impression from the volume that there is a demand for name change. in my opinion there isn't. certainly names is a rich topic and the discussion would never die down on it's own because it is so much fun. it's a wonder anything gets done... here is a summary of who's responded to our proposal and an indication of the topic. [EMAIL PROTECTED] +1 [EMAIL PROTECTED] +1 (MENTOR) [EMAIL PROTECTED] +1 (TOOMANY, NAME) [EMAIL PROTECTED] +1 (NAME) [EMAIL PROTECTED] +1 (TOOGOOD, TOOMANY, NAME, MENTOR) [EMAIL PROTECTED] +1 [EMAIL PROTECTED] +1 (TOOMANY, MENTOR) [EMAIL PROTECTED] (TOOMANY) [EMAIL PROTECTED] (NAME) [EMAIL PROTECTED] (QUESTION) [EMAIL PROTECTED] (NAME) [EMAIL PROTECTED] (NAME) [EMAIL PROTECTED] (NAME) [EMAIL PROTECTED] (TOOMANY) [EMAIL PROTECTED] (TOOMANY) [EMAIL PROTECTED] (NAME) of the people that mention name (8), only 3 are voting: henning: concerned about confusion with debian. only says we need to be careful and explicit. niall: wants to see the q resolved. likes the name, sees no real objection. niclas: conflict with debian; only worries about it. of the rest, most like the name etch and seem to be just "tossing the ball around". the main other concern is that of confusion with Debian Etch vs. Apache Etch. There was some discussion about whether etch could get to the top of the google list. so, can we put the name question to bed? it was suggested that the podling could/should decide the issue for itself, later. is there a problem with that? are there any other concerns about the proposal which aren't addressed? scott out -- Grant Ingersoll http://www.lucidimagination.com Lucene Helpful Hints: http://wiki.apache.org/lucene-java/BasicsOfPerformance http://wiki.apache.org/lucene-java/LuceneFAQ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Windmill
Hi Mikeal, Excellent answer, thanks very much for the clarification. I myself have enjoyed using Selenium in the past, and Windmill sounds like a definite improvement. It sounds great - I think it would be a worthwhile Incubator project. +1 (non-binding) Thanks, Les On Thu, Aug 14, 2008 at 6:19 PM, Mikeal Rogers <[EMAIL PROTECTED]>wrote: > Of those 3 it's the most like Selenium. > > As far as I know the "proxy spoof" method was pioneered by Selenium and > we've continued to use/evolve that method of "tricking" the browser's same > domain security policy. Our implementation of the test API has been very > different from selenium as is our proxy <-> javascript communication > workflow. > > Since our initial release we've done a lot of feature work around the > recording, debugging, and test editing workflows. We've also done a good > amount of work both in the proxy and in the javascript layer to make having > a single test move around different target domains remain seamless and > transparent. > > It's been a while since I used Selenium so I can't comment on their current > feature list compared to ours, but at the time we decided to write Windmill > we were incredibly frustrated with the process of maintaining tests written > in Selenium in an environment where the target product changed rapidly. We > found that debugging and editing a test after changes to the product to be > as difficult as writing the entire test all over again from scratch and have > continued to improve windmill around our own use cases as well as user > community feedback. > > I hope that answers your question, this was a fairly high level answer, if > you'd like I can go over any of those features/differences in more detail > and point you at any code. > > -Mikeal > > > On Aug 14, 2008, at August 14, 20081:40 PM, Les Hazlewood wrote: > > Just out of curiosity, where does this fit in versus, say, Selenium, MaxQ, >> Canoo WebTest, and others? >> >> There's nothing wrong if Windmill does the same stuff - I'm just curious >> what it can do in comparison. >> >> Cheers, >> >> Les >> >> On Thu, Aug 14, 2008 at 4:32 PM, Mikeal Rogers <[EMAIL PROTECTED] >> >wrote: >> >> This is a proposal to enter the incubator. >>> >>> See http://wiki.apache.org/incubator/WindmillProposal for the most >>> up-to-date version. >>> >>> We look forward to comments and discussion. >>> >>> = Abstract = >>> >>> The goal of Windmill is to build the best tool for automated testing of >>> dynamic Web applications across all major browsers. >>> >>> = Proposal = >>> >>> Windmill provides a full-stack automation solution for dynamic >>> Web-application testing. >>> >>> It accomplishes this by implementing an extensive test API in JavaScript, >>> and providing an intelligent proxy that can overcome the browser's >>> same-domain security policy. The test API allows a single test to run on >>> every major browser across all major operating systems. >>> >>> Windmill boasts a wide range of debugging and test-authoring tools that >>> make test writing, debugging, and editing a more streamlined process. >>> >>> = Background = >>> >>> Windmill was created at the Open Source Applications Foundation by Mikeal >>> Rogers and Adam Christian to test the Chandler Server Web UI. It was >>> announced more broadly at OSCON 2007 and has since enjoyed a wide range >>> of >>> use and contributions. >>> >>> In January 2008, all the full-time, paid contributors from OSAF moved on >>> to >>> other employment. The project has since retained steady contribution >>> despite >>> having no full-time, paid contributors. >>> >>> In July 2008, we proposed the project move its hosting away from OSAF >>> because of uncertainty about long term sustainability -- due to OSAF's >>> transition to a smaller-scale, mostly volunteer structure. >>> >>> = Rationale = >>> >>> Windmill was created to fulfill a need for a better dynamic >>> Web-application >>> testing tool after much frustration with existing solutions. We believe >>> it >>> has accomplished this goal and continues to improve, with ongoing, open >>> interaction with the community. >>> >>> What the project currently lacks is clear direction, leadership, and >>> process. We believe the project would benefit greatly from Incubator >>> mentorship, which would allow it to see much wider adoption, and grow a >>> broader community. >>> >>> = Current Status = >>> >>> == Meritocracy == >>> >>> Since the project's inception, its development has been coordinated >>> through >>> collaborative decision-making (e.g., "+1 voting") on the mailing list, >>> and >>> open discussion on IRC. >>> >>> == Community == >>> >>> Although the list of Core Developers has remained small we've welcomed >>> outside contributions. Along with a few small but good patches, we've >>> received some very good bugs and numerous features requests from the >>> community. Our wiki documentation is being continually improved by our >>> users. >>> >>> We also have a very good repu
Re: [PROPOSAL] Etch
It seems discussion has died down a bit. So to wrap up on the last issues discussed: I think we should just keep the name. We have quite a bit of goodwill invested in the name already and it is certainly no worse than other names that have been accepted into incubation. So unless there is a direct objection to incubation because of the name, lets just table it as a concern to monitor and move on. The only other issue that has been floating around is the size of the initial committers. Scott and I detailed various contributions explicitly and for those we did not callout in this list, we did call out in the proposal itself. All of the committers listed are active contributors to Etch today. There have been more contributors in the past and plenty in our circle of friends here at Cisco that would like to be contributors. But as I mentioned originally, we culled the list based on active contributors today. I understand that starting with 14 may mean staying in incubation "longer", but I do not necessarily think that is a bad thing. I am not in any race to finish incubation "quickly". If there is true interest in Etch, there will be plenty of contributors and the project will be better for it. So again, unless there is a specific, direct objection to incubation because of the length of the committer list, lets just table it, like the name, as a concern to monitor and move on. Give that, is there anything else that prevents us calling for a vote? -- james On 8/15/08 7:27 AM, "Grant Ingersoll" <[EMAIL PROTECTED]> wrote: > FWIW, I'm +1 on the proposal, regardless of the name. > > > On Aug 13, 2008, at 12:58 PM, scott comer wrote: > >> the discussion about names seems somewhat done. it is easy to get the >> impression from the volume that there is a demand for name change. in >> my opinion there isn't. certainly names is a rich topic and the >> discussion >> would never die down on it's own because it is so much fun. it's a >> wonder >> anything gets done... >> >> here is a summary of who's responded to our proposal and an indication >> of the topic. >> >> [EMAIL PROTECTED] +1 >> [EMAIL PROTECTED] +1 (MENTOR) >> [EMAIL PROTECTED] +1 (TOOMANY, NAME) >> [EMAIL PROTECTED] +1 (NAME) >> [EMAIL PROTECTED] +1 (TOOGOOD, TOOMANY, NAME, MENTOR) >> [EMAIL PROTECTED] +1 >> [EMAIL PROTECTED] +1 (TOOMANY, MENTOR) >> >> [EMAIL PROTECTED] (TOOMANY) >> [EMAIL PROTECTED] (NAME) >> [EMAIL PROTECTED] (QUESTION) >> [EMAIL PROTECTED] (NAME) >> [EMAIL PROTECTED] (NAME) >> [EMAIL PROTECTED] (NAME) >> [EMAIL PROTECTED] (TOOMANY) >> [EMAIL PROTECTED] (TOOMANY) >> [EMAIL PROTECTED] (NAME) >> >> of the people that mention name (8), only 3 are voting: >> >> henning: concerned about confusion with debian. only says we need to >> be careful and explicit. >> niall: wants to see the q resolved. likes the name, sees no real >> objection. >> niclas: conflict with debian; only worries about it. >> >> of the rest, most like the name etch and seem to be just "tossing >> the ball around". >> >> the main other concern is that of confusion with Debian Etch vs. >> Apache Etch. There >> was some discussion about whether etch could get to the top of the >> google list. >> >> so, can we put the name question to bed? it was suggested that the >> podling could/should >> decide the issue for itself, later. is there a problem with that? >> >> are there any other concerns about the proposal which aren't >> addressed? >> >> scott out >> > > -- > Grant Ingersoll > http://www.lucidimagination.com > > Lucene Helpful Hints: > http://wiki.apache.org/lucene-java/BasicsOfPerformance > http://wiki.apache.org/lucene-java/LuceneFAQ > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- James Dixson Manager, Software Development CUAE Engineering, Cisco Systems (e) [EMAIL PROTECTED] (p) 512-336-3305 (m) 512-968-2116 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Poloka
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 <[EMAIL PROTECTED]>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 cod
Re: [PROPOSAL] Etch
On Mon, 2008-08-18 at 12:33 -0500, James Dixson wrote: > It seems discussion has died down a bit. > > So to wrap up on the last issues discussed: > > I think we should just keep the name. We have quite a bit of goodwill > invested in the name already and it is certainly no worse than other names > that have been accepted into incubation. So unless there is a direct > objection to incubation because of the name, lets just table it as a concern > to monitor and move on. > > The only other issue that has been floating around is the size of the > initial committers. Scott and I detailed various contributions explicitly > and for those we did not callout in this list, we did call out in the > proposal itself. > > All of the committers listed are active contributors to Etch today. There > have been more contributors in the past and plenty in our circle of friends > here at Cisco that would like to be contributors. But as I mentioned > originally, we culled the list based on active contributors today. I > understand that starting with 14 may mean staying in incubation "longer", > but I do not necessarily think that is a bad thing. I am not in any race to > finish incubation "quickly". If there is true interest in Etch, there will > be plenty of contributors and the project will be better for it. So again, > unless there is a specific, direct objection to incubation because of the > length of the committer list, lets just table it, like the name, as a > concern to monitor and move on. > > Give that, is there anything else that prevents us calling for a vote? My expressed concern was to do with the length of the committer list. If you start with 14 committers, (and they all remain active) you won't be able to graduate until you reach at least 29 committers - so that there isn't a predominance from one organisation. 29 is a lot of committers for this kind of project. If you recruited one committer every two months, that would mean you'd be in incubation for nearly three years. Just trying to set some expectations. Having said that, if the project is prepared to go ahead on that basis, then I'm fine with it too, and would happily vote for it. I do think it is time for a vote. Regards, Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
It was suggested that the committer list be trimmed to those who will actually be committing (perhaps the 8 that Scott mentions). Those suggestions were not even acknowledged. Is there a problem with trimming the list? -Yonik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
I may have missed some of the threads on this, so apologize if this is a repeat. However, FWIW, I wanted to confirm that Etch isn't registered as a trademark or service mark with the US PTO for any software product or service, so there is no direct conflict with names in that venue. Jennifer On 8/18/08, Yonik Seeley <[EMAIL PROTECTED]> wrote: > > It was suggested that the committer list be trimmed to those who will > actually be committing (perhaps the 8 that Scott mentions). Those > suggestions were not even acknowledged. Is there a problem with > trimming the list? > > -Yonik > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
RE: [PROPOSAL] Etch
There is no problem trimming the list. As I mentioned originally, we included in the list all of the most recent active contributors. The question has been asked of the current contributors over the last several days and many of them have volunteered to step back. The proposal has been updated and there are now only 8 initial committers. --- James Dixson Manager, Software Development CUAE Engineering, Cisco Systems Inc. Direct: 512-336-3305 Mobile: 512-968-2116 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yonik Seeley Sent: Monday, August 18, 2008 4:18 PM To: general@incubator.apache.org Subject: Re: [PROPOSAL] Etch It was suggested that the committer list be trimmed to those who will actually be committing (perhaps the 8 that Scott mentions). Those suggestions were not even acknowledged. Is there a problem with trimming the list? -Yonik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Etch
On Wed, 2008-08-20 at 08:43 -0700, James Dixson (jadixson) wrote: > There is no problem trimming the list. As I mentioned originally, we > included in the list all of the most recent active contributors. > > The question has been asked of the current contributors over the last > several days and many of them have volunteered to step back. > > The proposal has been updated and there are now only 8 initial > committers. This is good. 8 is still on the higher side, but I think you'll have a much more pleasant incubation with this reduced number. Regards, Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal - Question
Hi César, Apache already hosts a couple of text related projects where your proposal might fit in. Mahout is a project for machine learning on Hadoop, and I think they already have text categorization. Another text related project is UIMA, which could also use a text categorizer. Not sure if Lucene also has a text categorizer, but I'm sure they could use one. I'd encourage you to check out these projects and see if you want to contribute to one of them. You may find that a text categorizer is somewhat small in scope to be an Apache project of its own, what with the necessary community building etc. --Thilo Cesar D. Rodas wrote: > Hello to all, > > My name is César Rodas, from Paraguay, I'm newbie in this mail list, so my > question may be recursive and quite stupid with a simple answer, so I ask > apologizes. > > I have a project, which I haven't start coding yet but I will start ASAP. > Basically it will be a Text Categorizer (Apache TextCat is a good name, > right?), that will be topics and language independent, that will learn by > examples. > > I was thinking to build it in C using APR, and I planning to build it very > modular, and really easy to extend. You may be wondering why C instead of > Java, and the answer is quite simple, I want the project run faster, and > that it can embedded, and wrapped from other languages, PHP, Python, Perl, > Java, etc. This is only my opinion. > > Further technicals details will be explained into my proposal. > > My question is, do I need to have something working to propose the project > to the Apache Incubator?, or I can propose a project that I'm planning to > code? > > Also, will be great if the folk can say what you think about this project?, > Will it be useful? > > > Kind Regards, > > P.D: As you can see,I can't write a perfect English, since I'm not a native > English speaker. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Poloka
Hello Serge, have you contacted the WebServices PMC about sponsoring this proposal? [EMAIL PROTECTED] seems to be a good place to pitch it and see how it fits into the existing web services projects at Apache. http://ws.apache.org/mail.html The "Mentors" section is somewhat irritating, as the Incubator also defines the role of a Mentor: http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Mentor Maybe you can rename the section to distinguish it from the "Nominated Members"? The "External Dependencies" section lists mysql-connector.jar as GPL-licensed. Is the code using that JAR directly, or does it access MySQL through a standard interface like JDBC? The "Required Resources" section is meant to list the resources you will need at Apache. "it exists" is not correct there, since currently no Apache resources have been created for you. The "Orphaned Projects" section says "no risk". There is always a risk... Requests from individuals to get source code is a sign of _potential_ users, which _potentially_ could become developers at some time. Major software companies can change their plans and cut the funding for working on an open source project. I wonder how the University Research Community will interact with an open source community. Students working on a project to get a degree might have a short-term interest, contributing for a few months then loosing interest once they get their degree - just when they could have become committers. So this involvement depends on either students picking up a personal long-term interest, or professors bringing in new students. There's nothing wrong with that, but bringing in new people requires some effort of the existing community to show them the way. You can't run a project only with short-termers. Also, community merit is earned by regular contributions over a period of time. Students working on the project will have to get involved in a continuous way, not by working secretly on their thesis and dropping the result onto the community in a big-bang style when they're done. Don't get me wrong: I'm not saying that all bad things will happen and that the project is going to collapse. Also, my university experience is somewhat outdated (10 years ago) and certainly not representative. But maybe you can change "no risk" to "low risk"? Turning several interested people and parties into a working open source community is not as easy as it may seem. The "Meritocracy" section sounds as if there is no meritocracy at all, and the "Community" section (...managed and organized by MSRG...) as well as the "Required Resources" section (...not available outside of the MSRG) add to that picture. From what I read, I believe you have a closed group of developers (=researchers+students) and that MSRG manages the development activities in a hierarchical way. There is a small mismatch between the lists of "Core Developers" and "Initial Committers". You are not mentioned as a core developer, but you probably will help with project organization, web site and other things. Arno Jacobsen is not mentioned as a core developer either, but the "Mentors" section says: Dr. Hans-Arno Jacobsen is the head of the Middleware Systems Research Group and he is leading all current research activities. Does the head and leader really find the time to get his hands dirty with the code and docs in the repository? Apache accounts are given to people who have a need for them. I'm not going to comment on the technical side of the proposal. Web services are not my area of expertise or interest. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
On Wed, Aug 20, 2008 at 9:30 PM, Upayavira <[EMAIL PROTECTED]> wrote: > On Wed, 2008-08-20 at 08:43 -0700, James Dixson (jadixson) wrote: >> There is no problem trimming the list. As I mentioned originally, we >> included in the list all of the most recent active contributors. >> >> The question has been asked of the current contributors over the last >> several days and many of them have volunteered to step back. >> >> The proposal has been updated and there are now only 8 initial >> committers. > > This is good. 8 is still on the higher side, but I think you'll have a > much more pleasant incubation with this reduced number. Sorry, for having been disconnected while on the road. Upayavira's concerns are valid, but I think it is now (8) not a showstopper for entry to Incubator. As he points out, it is not so much of an entry problem, but a graduation issue later. In theory, it is possible to trim the PPMC list prior to graduation according to those who have actually been active, but that doesn't happen too often. I am Ok to start a vote... Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Poloka
Hello Roland Thank you for the comments! It is encouraging to see that somebody undertook an effort of reading the proposal so carefuly and giving so many good comments! We have started a discussion with Davanum Shrinivas from the Apache WS community. We asked Davanum to Champion the project within Apache. Davanum suggested that we post the proposal in the Incubator list and in the Apache Savan development list. The idea is to create an open discussion that would determine how and where Poloka project would be sponsored. I have posted the proposal in the Savan list as well. Yeh, "Mentor" section of the proposal should be renamed. The idea here is to separate the developers working on the code from domain experts that are taking part in this projct. The Domain Experts are currently consulting developers on the intent of the standards and also on the domain of enterprise software systems from the point of view of future users. Would renaming this section to "Domain Experts" make sense to you? Regarding the GPL code. Our intent is to remove all GPL dependency from the code prior to the initial relaease. None of GPL dependencies will remain in the list. I agree that University Research Community and Open Source Community not the same, but they are similar in some respect. They are simmilar because there is constant sharing of ideas through publications, demos and conferences. Researches working in the same field often know each other personaly. They comment on each other work and give tips on how to move forward. They are diffent in terms of code charing. It is not happening a lot on the research side currently. And yes, we do not know exactly how it is going to work in this enviroment, but we are willing to give it a try by relasing our stuff in the open. We are interested in making it work. Resesach progress could go so much faster if it would really happen. We have good indicatation from our peers so far.We have a long list of researchers that indicated that they would like to see this stuff in the open and contribute to it. So far PADRES code base has been developed through constant interaction and continous integration. The codebase is open to everybody in the project and eveyone can poetentially make changes to everybody else's code. In fact this is happening a lot when a student is preparing to graduate or past graduation. We expect that there will be more of that once the project is open sourced. The students would charge ahaed working on their ideas. This code will be visible to the community and anybody would have ability to contribute to that direciton if it makes sense to them. Isn't it how Apache project operate? I think I already addressed your comment about meritocracy by describing how the team operates. Does it make sense? The time span a thesis development is 2-3 years. Sometimes a student would go for a master and a doctor thesis and then it might take twice as long. In fact Alex Cheung is one of the people like that. He has been with the project from day one and he is still there contributing actively. Prof. Arno Jacobsen is conducting regular code reviews and is involved in architecture, design, troubleshooting, evaluations, and experiments. You are right, he is expected to commit more on the documentation side than on the code base. Cheers, Serge -Original Message- From: Roland Weber [mailto:[EMAIL PROTECTED] Sent: Saturday, August 23, 2008 3:48 AM To: general@incubator.apache.org Subject: Re: [PROPOSAL] Poloka Hello Serge, have you contacted the WebServices PMC about sponsoring this proposal? [EMAIL PROTECTED] seems to be a good place to pitch it and see how it fits into the existing web services projects at Apache. http://ws.apache.org/mail.html The "Mentors" section is somewhat irritating, as the Incubator also defines the role of a Mentor: http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#M entor Maybe you can rename the section to distinguish it from the "Nominated Members"? The "External Dependencies" section lists mysql-connector.jar as GPL-licensed. Is the code using that JAR directly, or does it access MySQL through a standard interface like JDBC? The "Required Resources" section is meant to list the resources you will need at Apache. "it exists" is not correct there, since currently no Apache resources have been created for you. The "Orphaned Projects" section says "no risk". There is always a risk... Requests from individuals to get source code is a sign of _potential_ users, which _potentially_ could become developers at some time. Major software companies can change their plans and cut the funding for working on an open source project. I wonder how the University Research Community will interact with an open source community. Students working on a project to get a degree might have a short-term interest, contributing
Re: [PROPOSAL] Poloka
Hello Serge, thanks for the detailed reply. We have started a discussion with Davanum Shrinivas from the Apache WS community. [...] I have posted the proposal in the Savan list as well. Good. If discussion there moves forward, you could occasionally send a summary here for those that don't follow that list. Yeh, "Mentor" section of the proposal should be renamed. [...] Would renaming this section to "Domain Experts" make sense to you? Yes, that's good. Regarding the GPL code. Our intent is to remove all GPL dependency from the code prior to the initial relaease. That's good enough. I was just curious whether you really have a hard dependency at all, or whether it is just indirectly through a standard Java API. I agree that University Research Community and Open Source Community not the same, but they are similar in some respect. [...] we do not know exactly how it is going to work in this enviroment, but we are willing to give it a try by relasing our stuff in the open. We are interested in making it work. Resesach progress could go so much faster if it would really happen. We have good indicatation from our peers so far.We have a long list of researchers that indicated that they would like to see this stuff in the open and contribute to it. Excellent. So far PADRES code base has been developed through constant interaction and continous integration. The codebase is open to everybody in the project and eveyone can poetentially make changes to everybody else's code. In fact this is happening a lot when a student is preparing to graduate or past graduation. We expect that there will be more of that once the project is open sourced. The students would charge ahaed working on their ideas. This code will be visible to the community and anybody would have ability to contribute to that direciton if it makes sense to them. Isn't it how Apache project operate? You should be aware that you will not be able to just give students access to the Apache repository. They will have to contribute in the form of patches, which need to be reviewed and committed by others, until they have earned enough merit to be voted in as committers. I suspect that currently students will be given access to your repository as soon as they start working on the project. The continuous integration and "access to everything" policy work well with Open Source. The time span a thesis development is 2-3 years. That's good, and different from what I was used to. While studies would span several years, the work on the actual diploma thesis itself was typically done in about 6 months. Of course students could engage at an institute with a long-running project and work on that in different settings for a longer time, but that wasn't a requirement. Prof. Arno Jacobsen is conducting regular code reviews and is involved in architecture, design, troubleshooting, evaluations, and experiments. You are right, he is expected to commit more on the documentation side than on the code base. OK, thanks for clarifying. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Poloka
Hello Roland, Thanks for taking the time to go through the proposal. I have had the opportunity to work on PADRES project with Prof Arno and his team as part of a project course this summer (which ended a few weeks ago). My impression is that the current students have a good understanding of how open source works and realize the importance of collaboration. They were open to ideas and suggestions and were already using a mailing list and wiki for collaborating among themselves. Important decisions are discussed and made on the mailing list, similar to how an open source project is structured. Therefore I believe the transition to an Apache project will be a lot more easy as the folks involved are currently managing the project similar to the way a typical open source project would work. Also, I would like to volunteer as a mentor to help run the project the Apache way. I am a committer on Apache Axis2, Apache Synapse and Apache Qpid (and have contributed code to Geronimo and Tuscany) Most of my current time is spent at Apache Qpid which is currently in incubation. Therefore I am familiar with the way Apache works in general and in particular the incubation process, and the challenges associated with it. I would like to contribute that knowledge to help Poloka be successful at Apache. Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ On Tue, Aug 26, 2008 at 12:25 PM, Roland Weber <[EMAIL PROTECTED]> wrote: > Hello Serge, > > thanks for the detailed reply. > > We have started a discussion with Davanum Shrinivas from the Apache WS >> community. [...] I have posted the proposal in the Savan list as well. >> > > Good. If discussion there moves forward, you could occasionally > send a summary here for those that don't follow that list. > > Yeh, "Mentor" section of the proposal should be renamed. [...] >> Would renaming this section to "Domain Experts" make sense to you? >> > > Yes, that's good. > > Regarding the GPL code. Our intent is to remove all GPL dependency from >> the code prior to the initial relaease. >> > > That's good enough. I was just curious whether you really have > a hard dependency at all, or whether it is just indirectly > through a standard Java API. > > I agree that University Research Community and Open Source Community not >> the same, but they are similar in some respect. [...] we do not know >> exactly how it is going to work in this enviroment, but we are willing >> to give it a try by relasing our stuff in the open. We are interested in >> making it work. Resesach progress could go so much faster if it would >> really happen. We have good indicatation from our peers so far.We have a >> long list of researchers that indicated that they would like to see this >> stuff in the open and contribute to it. >> > > Excellent. > > So far PADRES code base has been developed through constant interaction >> and continous integration. The codebase is open to everybody in the >> project and eveyone can poetentially make changes to everybody else's >> code. In fact this is happening a lot when a student is preparing to >> graduate or past graduation. We expect that there will be more of that >> once the project is open sourced. The students would charge ahaed >> working on their ideas. This code will be visible to the community and >> anybody would have ability to contribute to that direciton if it makes >> sense to them. Isn't it how Apache project operate? >> > > You should be aware that you will not be able to just give > students access to the Apache repository. They will have to > contribute in the form of patches, which need to be reviewed > and committed by others, until they have earned enough merit > to be voted in as committers. I suspect that currently > students will be given access to your repository as soon as > they start working on the project. The continuous integration > and "access to everything" policy work well with Open Source. > > The time span a thesis development is 2-3 years. >> > > That's good, and different from what I was used to. > While studies would span several years, the work on > the actual diploma thesis itself was typically done > in about 6 months. Of course students could engage > at an institute with a long-running project and work > on that in different settings for a longer time, but > that wasn't a requirement. > > Prof. Arno Jacobsen is conducting regular code reviews and is involved >> in architecture, design, troubleshooting, evaluations, and experiments. >> You are right, he is expected to commit more on the documentation side >> than on the code base. >> > > OK, thanks for clarifying. > > > cheers, > Roland > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [PROPOSAL] Poloka
Btw, Apache ServiceMix also has a JBI service engine implementating WS-BrokeredNotification on top of a JMS broker (which btw saves a lot of work ...). It would be interesting to see if we can come up with something that could be shared by the three projects (Savan, Poloka and ServiceMix) ... On Wed, Aug 20, 2008 at 5:55 PM, Mankovskii, Serge <[EMAIL PROTECTED]> wrote: > I am re-sending this proposal because the first time it ended up in the > Etch proposal thread. Sorry Etch guys! > > > > > > 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 cod
RE: [PROPOSAL] Poloka
Hi Guillaume, This is interesting! Thank you for the tip on ServiceMix. I will take a look in the ServiceMix code. Do you think it would make sense to send the Poloka proposal to the ServiceMix mailing list? Cheers Serge -Original Message- From: Guillaume Nodet [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 5:05 PM To: general@incubator.apache.org Subject: Re: [PROPOSAL] Poloka Btw, Apache ServiceMix also has a JBI service engine implementating WS-BrokeredNotification on top of a JMS broker (which btw saves a lot of work ...). It would be interesting to see if we can come up with something that could be shared by the three projects (Savan, Poloka and ServiceMix) ... On Wed, Aug 20, 2008 at 5:55 PM, Mankovskii, Serge <[EMAIL PROTECTED]> wrote: > I am re-sending this proposal because the first time it ended up in the > Etch proposal thread. Sorry Etch guys! > > > > > > 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. > > &
Re: [PROPOSAL] Poloka
Yeah, one of our user wants to contribute new features to the WS notification broker, so she may be interested. FYI, the WS-Notification service engine code is located here: https://svn.apache.org/repos/asf/servicemix/components/engines/servicemix-wsn2005/trunk/ We're using CXF wsdl2java tool to generate the classes and interfaces from the WSDL, then provide implementation of those on top of a JMS broker. On Thu, Sep 4, 2008 at 5:56 PM, Mankovskii, Serge <[EMAIL PROTECTED]> wrote: > Hi Guillaume, > > This is interesting! Thank you for the tip on ServiceMix. I will take a > look in the ServiceMix code. > > Do you think it would make sense to send the Poloka proposal to the > ServiceMix mailing list? > > > Cheers > Serge > > > -Original Message- > From: Guillaume Nodet [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 03, 2008 5:05 PM > To: general@incubator.apache.org > Subject: Re: [PROPOSAL] Poloka > > Btw, Apache ServiceMix also has a JBI service engine implementating > WS-BrokeredNotification on top of a JMS broker (which btw saves a lot > of work ...). It would be interesting to see if we can come up with > something that could be shared by the three projects (Savan, Poloka > and ServiceMix) ... > > On Wed, Aug 20, 2008 at 5:55 PM, Mankovskii, Serge > <[EMAIL PROTECTED]> wrote: >> I am re-sending this proposal because the first time it ended up in > the >> Etch proposal thread. Sorry Etch guys! >> >> >> >> >> >> 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 >> broke
Re: [PROPOSAL] Etch
Upayavira wrote: My expressed concern was to do with the length of the committer list. If you start with 14 committers, (and they all remain active) you won't be able to graduate until you reach at least 29 committers - so that there isn't a predominance from one organisation. I've always understood the rule of thumb counted organizations represented, not committers. Since most votes permit a veto, having a majority of committers doesn't grant one control of a project. If there are 14 committers from one organization, then my interpretation of the rule of thumb is that we need to be at least two from two other organizations. It is of course just a rule of thumb. 14 from one organization and only two from others indeed wouldn't smell right. But I don't believe that there's a hard-and-fast rule that 15 committers from other organizations must be added before it could graduate. Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Catacomb
On Fri, Sep 19, 2008 at 1:55 AM, <[EMAIL PROTECTED]> wrote: > This is a proposal to enter the incubator. > > See http://wiki.apache.org/incubator/CatacombProposal for the most > up-to-date version. Nifty! > As Champion we have Gianugo Rabellino from the > ASF. > > We look forward to comments and discussion. If you're looking for more mentors, I'll volunteer. Though, if enough other people step up, I'll gladly defer; but I'm happy to help mentor this. (I know a fair chunk of the initial committers.) A possibility is for Catacomb to eventually be folded into the HTTP Server Project, but I don't know if that is the 'best' thing to do or not. We can incubate it, see where it goes, and then decide on that later on. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Catacomb
On Sun, Sep 21, 2008 at 9:45 AM, <[EMAIL PROTECTED]> wrote: > Hello Justin, > > we would be glad to welcome you as a mentor for catacomb incubation process! > Your idea to fold catacomb into the HTTP > Server Project is realy nice, maybe later in the incubation process we could > start a discussion with someone from the HTTP Server Project. Yup, we can cross that bridge later. > Can you tell us what is the next step for catacomb to get into the incubation > process? Let the proposal sit for another few days, then we can call a vote for accepting the proposal. Ideally, it'd be nice to find another mentor besides me and Gianugo. (Is Gianugo around? I haven't seen him on-list in a long time.) -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Droids
This sounds good to me. Are you planning to run Droids on top of Hadoop? If not, why not? Thanks, Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message > From: Thorsten Scherler <[EMAIL PROTECTED]> > To: general@incubator.apache.org > Sent: Monday, September 22, 2008 4:24:55 PM > Subject: [PROPOSAL] Droids > > This is a proposal to enter the incubator. > > See http://wiki.apache.org/incubator/DroidsProposal for the most > up-to-date version. > > As Champion we have Grant Ingersoll from > the ASF. > > Droids is an Apache Labs project and we are still looking for some > mentors for this proposal. > > We look forward to comments and discussion. > > = Droids, an intelligent standalone robot framework = > > === Abstract === > > Droids aims to be an intelligent standalone robot framework that allows > to create and extend existing droids (robots). > > === Proposal === > > As a standalone robot framework Droids will offer infrastructure code to > create and extend existing robots. In the future it will offer as well a > web based administration application to manage and controll the > different droids which will communicate with this app. > > Droids makes it very easy to extend existing robots or write a new one > from scratch, which can automatically seek out relevant online > information based on the user's specifications. Since the flexible > design it can reuse directly all custom business logic that are written > in java. > > In the long run it should become umbrella for specialized droids that > are hosted as sub-projects. Where an ultimate goal is to integrate an > artificial intelligence that can control a swarm of droids and actively > plan/react on different tasks. > > === Background === > > The initial idea for the Droids project was voiced in February 2007 from > Thorsten Scherler mainly because of personal curiosity and developed as > a labs project. The background of his work was that Cocoon trunk (2.2) > did not provide a crawler anymore and Forrest was based on it, meaning > we could not update anymore till we found a crawler replacement. Getting > more involved in Solr and Nutch he saw the request for a generic > standalone crawler. > > For the first version he took nutch, ripped out and modified the > plugin/extension framework. However the second version were not based on > it anymore but was using Spring instead. The main reason was that Spring > has become a standard and helped to make Droids as extensible as > possible. > > Soon the first plugins and sample droids had been added to the code > based. > > === Rationale === > > There is ever more demand for tools that automatically do determinate > tasks. Search engines such as Nuts are normally very focused on a > specific functionality and are not focused on extensibility. Furthermore > there are manly focused on crawling, requesting certain pages and > extract links to other pages, which in our opinion is only one small > area for automated robots. While there are a number of existing crawler > libraries for various task, each of them comes with a custom API and > there are no generic interface for automatically determining which > crawler (droids) to use for a specific task. > > The Droids project attempts to remove this duplication of efforts. We > believe that by pooling the efforts of multiple projects we will be able > to create a generic robot framework that exceeds the capabilities and > quality of the custom solutions of any single project. The focus of > Droids is not a single crawler but more to offer different reusable > components that custom droids (robots) can use to automate certain > tasks. An intelligent standalone robot framework project will not only > provide common ground for the developers of crawler but as well for any > other automated application (robots) libraries. > > === Initial Goals === > > The initial goals of the proposed project are: > > * Viable community around the Droids codebase > * Active relationships and possible cooperation with related projects > and communities (e.g. reusing Tika for text extraction) > * Generic robot API for crawling, extracting structured text content > and/or new task, filtering task and handle the content > * Flexible extension and plugin development to create a wide range of > functionality > * Fuel develop of various droids and bring the current wget style > crawler to state-of-the-art level > > == Current Status == > > === Meritocracy === > > All the initial committers are familiar with the meritocracy principles > of Apache, and have already worked on the various source codebases. We > will follow the normal meritocracy rules also with other potential > contributors. > > === Community === > > There is not yet a clear Droids community. Instead we have a number of > people and related projects with an understanding that an intelligent > standalone robot framework project would best serve everyone's > in
Re: [PROPOSAL] Droids
On Mon, 2008-09-22 at 14:31 -0700, Otis Gospodnetic wrote: > This sounds good to me. > Are you planning to run Droids on top of Hadoop? Apache Droids aims to be a component framework for robots. Meaning that "Apache Droids" has just a couple direct dependencies (logging, ...). However components, such as plugins and robots (droids) can integrate whatever they want. > If not, why not? I gladly welcome a queue implementation for Apache Droids that is build on top of hadoop. However that is ATM not very high on our todo list since more basic stuff still needs some attention. The short goal is to provide a couple of droids that can serve for the typical one-box crawling use-cases (being wget or nutch like). As soon we reached enough components we will look into support distributed queues. However as always: patches are welcome. ;) Cheers Otis for your feedback. salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Catacomb
On Sep 22, 2008, at 7:47 PM, Justin Erenkrantz wrote: (Is Gianugo around? I haven't seen him on-list in a long time.) Sorta. Fighting with extensive travel and an overzealous GMail spam filter that insists in sweeping interesting stuff under the rug... Still, listening and lurking. Ciao, -- Gianugo Rabellino Sourcesense - making sense of Open Source: http://www.sourcesense.com Blogging at http://boldlyopen.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Droids
Thorsten Scherler wrote: This is a proposal to enter the incubator. See http://wiki.apache.org/incubator/DroidsProposal for the most up-to-date version. I'm happy to mentor this proposal. Ross - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Droids
On Tue, 2008-09-23 at 10:29 +0100, Ross Gardler wrote: > Thorsten Scherler wrote: > > This is a proposal to enter the incubator. > > > > See http://wiki.apache.org/incubator/DroidsProposal for the most > > up-to-date version. > > > I'm happy to mentor this proposal. :) Thank you very much Ross, I added your name to the proposal. salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Droids
I'm happy to mentor as well. I've added my name to the proposal. Paul On Tue, Sep 23, 2008 at 11:08 AM, Thorsten Scherler <[EMAIL PROTECTED]> wrote: > On Tue, 2008-09-23 at 10:29 +0100, Ross Gardler wrote: >> Thorsten Scherler wrote: >> > This is a proposal to enter the incubator. >> > >> > See http://wiki.apache.org/incubator/DroidsProposal for the most >> > up-to-date version. >> >> >> I'm happy to mentor this proposal. > > :) > > Thank you very much Ross, I added your name to the proposal. > > salu2 > -- > Thorsten Scherler thorsten.at.apache.org > Open Source Java consulting, training and solutions > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
