[VOTE] Accept Wicket into the Incubator
Folks, Without further ado (and before my PC dies again), I'd like to call a vote on accepting Wicket into the incubator. As previously mentioned, the Wicket community held a unanimous vote to approach the incubator. The vote thread is here: http://www.mail-archive.com/wicket-develop@lists.sourceforge.net/index.html#08808 Below is the complete proposal for this project. So, please cast your votes: [ ] +1 Accept Wicket as an Incubator podling [ ] 0 Don't care [ ] -1 Reject this proposal for the following reason: Regards, Upayavira - o - = Wicket Proposal = This proposal outlines the creation of a new top-level Wicket project within the Apache Software Foundation. == Rationale == Wicket is a unique web application framework that focusses on bringing plain object oriented Java programming to the web tier. It is unique in it's focus amongst the (many) web frameworks that exist today. Due to it's unmanaged nature and reliance on plain Java, it is a very good match for frameworks like OSGi and Eclipse RSP. Wicket has been gaining a very steady increase in popularity, and with two books coming out and vastly improved new releases we are working on, we expect this trend to continue. We consider moving to Apache being an additional boost, and we hope it will open the way for possible future cooperation with other Apache projects. The maintainers of Wicket are interested in joining the Apache Software Foundation for several reasons: * Apache has a widely recognized name, which will help Wicket get an increased visibility and acceptance. * We'd like to enjoy the benefits of utilizing Apache's infrastructure and legal protection. * Most team members have been enthusiastic users of Apache software for many years and would like to be part of the family with it's get togethers etc. * It might open the door for cooperation with other projects, such as Felix or Jetspeed. * Apache seems to attract great communities around its projects, we hope joining Apache will help as make our growing community even bigger. * We hope to contribute to Apache's ongoing success by delivering an innovative, dynamic project with an enthusiastic user base. == Criteria == === Community === Wicket has striven to foster a diverse community that is open to everyone. It is released under a non-reciprocal license (Apache License 2.0) to encourage the maximum possible adoption by all potential users and developers. The Wicket community encourages suggestions and contributions from any potential user, and more developers have joined as contributors since the project's inception in 2004. === Meritocracy === Wicket was originally created by Jonathan Locke in April 2004. Then it was taken over in September 2004 by Eelco Hillenius, Johan Compagner and Martijn Dashorst. Chris Turner and Juergen Donnerstag were invited to join that same week based on their contributions and discussions. The project now has committers and users from around the world, and Jonathan Locke is back with the project again. The newer committers of the project joined in subsequent years by initially submitting patches, then having commit privileges for some of the applications (wicket-stuff), and then privileges over a larger range of applications. The project members understand the importance of letting motivated individuals contribute to the project after they have proven themselves. == Scope of Sub projects == Wicket is distributed as one large subversion tree, but contains several distinct parts: the core framework, a couple of extensions project that are endorsed by the core developers, an examples project (which includes a component reference), a quick start project and a developer sandbox. One of the extensions projects, called wicket-extensions, has a dual purpose. The first is to ensure the core project does not get too large, while still having a place to put interesting components and utility classes. The second purpose of that project is to provide a place where components can prove themselves before potentially graduating to the core project. Whilst Wicket has these various subprojects, access to the subversion tree is maintained with a single ACL. Once voted in as a committer, an individual will have access to the entire tree, and trust is used to ensure that they only touch the parts of the tree that they are knowledgeable enough to change. == Features == Wicket is a Java web application framework that takes simplicity, separation of concerns and ease of development to a whole new level. Wicket pages can be mocked up, previewed and later revised using standard WYSIWYG HTML design tools. Dynamic content processing and form handling is all handled in Java code using a first-class component model backed by POJO data beans that can easily be persisted using your favorite technology. == Initial Source == The source for Wicket that is to be imported is currently within the Wicket project at SourceForge,
Oops (was Re: [VOTE] Accept Wicket into the Incubator)
Searching for '[VOTE]' on the wicket archives isn't enough to find the relevant vote :-( Here's the correct link: http://www.mail-archive.com/wicket-develop@lists.sourceforge.net/index.html#08853 Upayavira Upayavira wrote: Folks, Without further ado (and before my PC dies again), I'd like to call a vote on accepting Wicket into the incubator. As previously mentioned, the Wicket community held a unanimous vote to approach the incubator. The vote thread is here: http://www.mail-archive.com/wicket-develop@lists.sourceforge.net/index.html#08808 Below is the complete proposal for this project. So, please cast your votes: [ ] +1 Accept Wicket as an Incubator podling [ ] 0 Don't care [ ] -1 Reject this proposal for the following reason: Regards, Upayavira - o - = Wicket Proposal = This proposal outlines the creation of a new top-level Wicket project within the Apache Software Foundation. == Rationale == Wicket is a unique web application framework that focusses on bringing plain object oriented Java programming to the web tier. It is unique in it's focus amongst the (many) web frameworks that exist today. Due to it's unmanaged nature and reliance on plain Java, it is a very good match for frameworks like OSGi and Eclipse RSP. Wicket has been gaining a very steady increase in popularity, and with two books coming out and vastly improved new releases we are working on, we expect this trend to continue. We consider moving to Apache being an additional boost, and we hope it will open the way for possible future cooperation with other Apache projects. The maintainers of Wicket are interested in joining the Apache Software Foundation for several reasons: * Apache has a widely recognized name, which will help Wicket get an increased visibility and acceptance. * We'd like to enjoy the benefits of utilizing Apache's infrastructure and legal protection. * Most team members have been enthusiastic users of Apache software for many years and would like to be part of the family with it's get togethers etc. * It might open the door for cooperation with other projects, such as Felix or Jetspeed. * Apache seems to attract great communities around its projects, we hope joining Apache will help as make our growing community even bigger. * We hope to contribute to Apache's ongoing success by delivering an innovative, dynamic project with an enthusiastic user base. == Criteria == === Community === Wicket has striven to foster a diverse community that is open to everyone. It is released under a non-reciprocal license (Apache License 2.0) to encourage the maximum possible adoption by all potential users and developers. The Wicket community encourages suggestions and contributions from any potential user, and more developers have joined as contributors since the project's inception in 2004. === Meritocracy === Wicket was originally created by Jonathan Locke in April 2004. Then it was taken over in September 2004 by Eelco Hillenius, Johan Compagner and Martijn Dashorst. Chris Turner and Juergen Donnerstag were invited to join that same week based on their contributions and discussions. The project now has committers and users from around the world, and Jonathan Locke is back with the project again. The newer committers of the project joined in subsequent years by initially submitting patches, then having commit privileges for some of the applications (wicket-stuff), and then privileges over a larger range of applications. The project members understand the importance of letting motivated individuals contribute to the project after they have proven themselves. == Scope of Sub projects == Wicket is distributed as one large subversion tree, but contains several distinct parts: the core framework, a couple of extensions project that are endorsed by the core developers, an examples project (which includes a component reference), a quick start project and a developer sandbox. One of the extensions projects, called wicket-extensions, has a dual purpose. The first is to ensure the core project does not get too large, while still having a place to put interesting components and utility classes. The second purpose of that project is to provide a place where components can prove themselves before potentially graduating to the core project. Whilst Wicket has these various subprojects, access to the subversion tree is maintained with a single ACL. Once voted in as a committer, an individual will have access to the entire tree, and trust is used to ensure that they only touch the parts of the tree that they are knowledgeable enough to change. == Features == Wicket is a Java web application framework that takes simplicity, separation of concerns and ease of development to a whole new level. Wicket pages can be mocked up, previewed and later revised using standard
Re: [VOTE] Accept Wicket into the Incubator
On Thursday 24 August 2006 15:02, Upayavira wrote: So, please cast your votes: [x] +1 Accept Wicket as an Incubator podling (non-binding) Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Wicket into the Incubator
+1 (non-binding) regards, Martin On 8/24/06, Niclas Hedhman [EMAIL PROTECTED] wrote: On Thursday 24 August 2006 15:02, Upayavira wrote: So, please cast your votes: [x] +1 Accept Wicket as an Incubator podling (non-binding) Cheers Niclas - 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] Fluoride
On Wed, Aug 23, 2006 at 05:51:33PM -0400, Yoav Shapira wrote: Do proposed projects by current ASF members need official mentors and champions who are different than the proposer? Good question. This is the first time we have one like this :) What Noel and others have said in the past is essentially you need 3 +1s from ASF members (and sometimes incubator PMC members instead, I guess what matters is somehow minimum bindingness). Which I sorta agree with. That said, I wouldn't suggest starting on something without having a real good feeling about having enough people to commit time to something. I'd be interested in participating in this, but I can't commit much bandwidth, so I'll probably just lurk on the mailing lists if/when they're created. Same here. I'm a very enthousiastic +0 just on the basis that its not java ;-P LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Wicket into the Incubator
On Thu, Aug 24, 2006 at 12:02:53AM -0700, Upayavira wrote: Without further ado (and before my PC dies again), I'd like to call a vote on accepting Wicket into the incubator. snip/ = Wicket Proposal = This proposal outlines the creation of a new top-level Wicket project within the Apache Software Foundation. == Rationale == Wicket is a unique web application framework that focusses on bringing plain object oriented Java programming to the web tier. It is unique in it's focus amongst the (many) web frameworks that exist today. Due to it's unmanaged nature and reliance on plain Java, it is a very good match for frameworks like OSGi and Eclipse RSP. Wicket has been gaining a very steady increase in popularity, and with two books coming out and vastly improved new releases we are working on, we expect this trend to continue. We consider moving to Apache being an additional boost, and we hope it will open the way for possible future cooperation with other Apache projects. snip/ +1 LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Fluoride
On 24/08/2006, at 8:29 PM, Greg Stein wrote: The original proposal: bluntly: f*k the g*dm*d users list. You got zero code, so there is no purpose to a users list. Fork that out of the dev list if/when it is appropriate. I'd even suggest sending all commits to the dev list to start with. All initial developers should see all commits. When the project grows, then fine: split it. But if you have two (oh, sorry, one!) developers, then why two lists? fair comment... a single list will do nicely That said, I'm not quite sure where this fits in. Is the idea to get, say, all people in the (corporate) department to subscribe to their feeds via this software? Or is it more a site publishing N feeds should do it via this software? I'm assuming the latter, in which case, I'd be a little more interested in whether this software is intended to be the primary feed producer (from arbitrary data sources), or will an alternate republishing of a site's feeds. It's the later. They way I was envisioning was a publisher would have a set of N feeds the software would respond to a ping, and/or perform a poll on a regular schedule, and would fetch source feed and store it. this source feed would then be pre-processed by whatever is configured via a hook. when a user fetches the feed, he would do it via a personalized url. The source feed would then be adjusted and all external links would be personalized. (similar to what is currently done with email newsletters) and and another hook would be called so the publisher would be able to insert a advertisement, a web-bug or picture of a banana. when a personalized link is clicked, a hook would be called, ( say to add cookies back to the request if they aren't there) and then be redirected to the source URL. that's how I envisioned it working. It would also need a library php/ java/ruby... to generate the customized feed URLs to be displayed on the source pages. (something like /aggy/feed/atom/55a53ab418c5a6ae986fdb2dc2373d8d/ for example ) It could also be used as a RSS cache without any of the post-processing. for example, when your software has to do 100+ queries to generate your RSS feed for every request. Cheers, -g --Ian -- Ian Holsman [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Wicket into the Incubator
On 8/24/06, Ersin Er [EMAIL PROTECTED] wrote: ... Wicket vs. Struts: http://www.wicket-wiki.org.uk/wiki/index.php/Struts Bleh. That page confuses a lot of things. It conflates disparate components (e.g. Struts and JSP) in order to form opinions. It appears that Wicket also does state management as a benefit which I've rarely found to be true (any state in your http server kills scalability). And it somehow argues that Struts cannot handle multiple components on a page because they all go to one response handler for actions? Euh... seems each component would specify its own handler. On a pro, it seems to talk smack about JSP. Good. On a con, it uses a lot of buzzwords to try to demonstrate superiority. I don't know how Wicket is fully object-oriented. You work with hierarchies of components and design your application as such. There is no need to bend your oo design to fit with the request-response nature of the HTTP protocol. will really help. The web *is* request/response. Whatever. ETIMEOUT. -0 (binding) Cheers, -g -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Wicket into the Incubator
I've never used Wicket, but I've done a fair number of webapps using similar component frameworks, such as WebObjects and Tapestry. All I can say - it is hard to argue about component frameworks with people who never used them. The benefit is essentially a different more developer-friendly abstraction. Of course it ties to the request/ response protocol. Wicket site does seem to be heavy on marketing talk. While I find it very annoying (although this probably serves them in converting the masses), this doesn't mean it is a bad framework :-) Andrus On Aug 24, 2006, at 3:23 PM, Greg Stein wrote: On 8/24/06, Ersin Er [EMAIL PROTECTED] wrote: ... Wicket vs. Struts: http://www.wicket-wiki.org.uk/wiki/index.php/ Struts Bleh. That page confuses a lot of things. It conflates disparate components (e.g. Struts and JSP) in order to form opinions. It appears that Wicket also does state management as a benefit which I've rarely found to be true (any state in your http server kills scalability). And it somehow argues that Struts cannot handle multiple components on a page because they all go to one response handler for actions? Euh... seems each component would specify its own handler. On a pro, it seems to talk smack about JSP. Good. On a con, it uses a lot of buzzwords to try to demonstrate superiority. I don't know how Wicket is fully object-oriented. You work with hierarchies of components and design your application as such. There is no need to bend your oo design to fit with the request-response nature of the HTTP protocol. will really help. The web *is* request/response. Whatever. ETIMEOUT. -0 (binding) Cheers, -g -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jini : Separate Governance and Implementation Projects
Niclas Hedhman wrote: On Monday 21 August 2006 03:24, Mark Brouwer wrote: I would be saddened if we can't maintain Jini as project name I think Mark has put it rather well. The Jini community want a water cooler to gather around. Brilliant :-) -- Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Wicket into the Incubator
[X] +1 Accept Wicket as an Incubator podling /Gwyn P.S. We'll be happy to discuss Why Wicket or the Wicket homepage marketing-speak, but I don't think this thread's the place to do it! -- Download Wicket 1.2.1 now! - http://wicketframework.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Wicket into the Incubator
Upayavira wrote: So, please cast your votes: [X] +1 Accept Wicket as an Incubator podling [ ] 0 Don't care [ ] -1 Reject this proposal for the following reason: +1 Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Wicket into the Incubator
+1 On 24 Aug 06, at 3:02 AM 24 Aug 06, Upayavira wrote: Folks, Without further ado (and before my PC dies again), I'd like to call a vote on accepting Wicket into the incubator. As previously mentioned, the Wicket community held a unanimous vote to approach the incubator. The vote thread is here: http://www.mail-archive.com/wicket-develop@lists.sourceforge.net/ index.html#08808 Below is the complete proposal for this project. So, please cast your votes: [ ] +1 Accept Wicket as an Incubator podling [ ] 0 Don't care [ ] -1 Reject this proposal for the following reason: Regards, Upayavira - o - = Wicket Proposal = This proposal outlines the creation of a new top-level Wicket project within the Apache Software Foundation. == Rationale == Wicket is a unique web application framework that focusses on bringing plain object oriented Java programming to the web tier. It is unique in it's focus amongst the (many) web frameworks that exist today. Due to it's unmanaged nature and reliance on plain Java, it is a very good match for frameworks like OSGi and Eclipse RSP. Wicket has been gaining a very steady increase in popularity, and with two books coming out and vastly improved new releases we are working on, we expect this trend to continue. We consider moving to Apache being an additional boost, and we hope it will open the way for possible future cooperation with other Apache projects. The maintainers of Wicket are interested in joining the Apache Software Foundation for several reasons: * Apache has a widely recognized name, which will help Wicket get an increased visibility and acceptance. * We'd like to enjoy the benefits of utilizing Apache's infrastructure and legal protection. * Most team members have been enthusiastic users of Apache software for many years and would like to be part of the family with it's get togethers etc. * It might open the door for cooperation with other projects, such as Felix or Jetspeed. * Apache seems to attract great communities around its projects, we hope joining Apache will help as make our growing community even bigger. * We hope to contribute to Apache's ongoing success by delivering an innovative, dynamic project with an enthusiastic user base. == Criteria == === Community === Wicket has striven to foster a diverse community that is open to everyone. It is released under a non-reciprocal license (Apache License 2.0) to encourage the maximum possible adoption by all potential users and developers. The Wicket community encourages suggestions and contributions from any potential user, and more developers have joined as contributors since the project's inception in 2004. === Meritocracy === Wicket was originally created by Jonathan Locke in April 2004. Then it was taken over in September 2004 by Eelco Hillenius, Johan Compagner and Martijn Dashorst. Chris Turner and Juergen Donnerstag were invited to join that same week based on their contributions and discussions. The project now has committers and users from around the world, and Jonathan Locke is back with the project again. The newer committers of the project joined in subsequent years by initially submitting patches, then having commit privileges for some of the applications (wicket-stuff), and then privileges over a larger range of applications. The project members understand the importance of letting motivated individuals contribute to the project after they have proven themselves. == Scope of Sub projects == Wicket is distributed as one large subversion tree, but contains several distinct parts: the core framework, a couple of extensions project that are endorsed by the core developers, an examples project (which includes a component reference), a quick start project and a developer sandbox. One of the extensions projects, called wicket-extensions, has a dual purpose. The first is to ensure the core project does not get too large, while still having a place to put interesting components and utility classes. The second purpose of that project is to provide a place where components can prove themselves before potentially graduating to the core project. Whilst Wicket has these various subprojects, access to the subversion tree is maintained with a single ACL. Once voted in as a committer, an individual will have access to the entire tree, and trust is used to ensure that they only touch the parts of the tree that they are knowledgeable enough to change. == Features == Wicket is a Java web application framework that takes simplicity, separation of concerns and ease of development to a whole new level. Wicket pages can be mocked up, previewed and later revised using standard WYSIWYG HTML design tools. Dynamic content processing and form handling is all handled in Java code using a first-class component model backed by POJO data beans that can easily be persisted using your favorite technology. ==
Joining Incubator PMC (was Re: [VOTE] Accept Wicket into the Incubator)
Bertrand Delacretaz wrote: On 8/24/06, Upayavira [EMAIL PROTECTED] wrote: ...=== Name === Obviously, the ... Looks like something's missing on that line, it ends after Obviously, the. Not having a good day. That was where I started saying that I'd done a US trademark search that showed nothing, but decided not to mention it. Apart from that: +1. Not sure if binding or not, I've signed up as a mentor for Wicket but didn't participate in incubator activities before. Currently non-binding. But, as an ASF member, you should ask the Incubator PMC to join. Once you've joined, your votes will become binding. (at least that is my understanding) Regards, Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIni Proposal
While we continue to look forward to your review and response ;-) thought I'd mention a Jini event coming up next month: * Tenth Jini Community Meeting Brussels, Belgium September 13-14, 2006 * * Session Abstracts: http://www.jini.org/wiki/10th_JCM_Sessions * Schedule: http://www.jini.org/wiki/10th_JCM_Agenda_Day_1 http://www.jini.org/wiki/10th_JCM_Agenda_Day_2 It would be great to have Apache members there. The meeting is open and free, and all interested developers are welcome. We are hoping to provide an update on our Jini Proposal at the meeting (the Update on the Community talk on the first day is a placeholder whilst we get a better understanding on where our Proposal sits with the incubator). thanks -Jim On Aug 22, 2006, at 3:18 PM, Jim Hurley wrote: We've had some good and spirited discussion on the JiniProposal over the last couple weeks. Thanks to everyone who chimed in with your thoughts and opinions. In reviewing the discussion again, I think we can focus on three key items which seem to be at the root of some debate. For each item, I'll try and propose a path forward and we'll see where we go from there. Thanks again, and we look forward to your review and response. -Jim -- 1) specifications / API docs It appears that there are many (valid) lenses in which to view the specifications question. I'd rather not reintroduce all of the different perspectives and proposals, but rather focus on one that we believe is acceptable to the Jini Community, and hopefully will be to Apache. We would like to include the API docs (specifications seems to be a loaded term, with many different definitions and assumptions tied up in it) in the project. Many of the API docs are generated directly from the code (Javadoc), but would be made available as a separate download within the project. These would not be called standards. They would be called Jini API documents. They are intended to clearly define the APIs and semantics that are implemented as part of the project. Outside parties certainly have the right, and are welcome to use those docs to create alternative implementations - but that is not the predominant reason for producing the docs. The process used for introducing a change to the API docs would be developed by the project PMC and committers. We'd expect it to follow a similar process to proposed code mods, with the added responsibilities of making them visible to the overall Jini Community through the project email lists, and having open discussion and debate. We'd expect that the Community feedback would heavily influence the work performed on the API docs. The (perfectly reasonable) suggestion on creating a separate project for the governance of the specifications is not viable as we do not have the volunteers to run another project, nor was the intention of defining a specifications process within Apache something that the initial committers of our Proposal wanted or can satisfy. ------------ ------ 2) Java package names (namespace) There are two namespaces that are part of the Proposal that have been discussed: * net.jini.* -- this is the primary Jini namespace defined in the API docs, and chiefly for compatibility reasons with existing implementations and applications, we can not change this. * com.sun.jini.* -- there are also some compatibility issues associated with changing this namespace in the implementation, but we understand the reasons for wanting to change this to org.apache.projectname, and would do this as part of the incubation phase of the project. ------------ ------ 3) project name There is some pretty strong sentiment within the Jini Community for keeping the Jini name as part of the Apache Proposal. Our overall reading, however, is that given the scope of the project proposed and other technology sites (jini.dev.java.net, Jini.org) on the web, that the name would not be acceptable to Apache. We, therefore, are open to discussing a name change to something else within the Jini Community. If there's agreement on the positions stated in 1 and 2 above, we'll assume there's general support for our Proposal to Apache and begin the name discussion in the Jini Community. -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIni Proposal
Niclas Hedhman wrote: On Wednesday 23 August 2006 03:18, Jim Hurley wrote: We, therefore, are open to discussing a name change to something else within the Jini Community. If there's agreement on the positions stated in 1 and 2 above, we'll assume there's general support for our Proposal to Apache and begin the name discussion in the Jini Community. Isn't it a bit odd to keep net.jini (which I think is essential for compatibility reasons), and not have Jini in the name of the responsible body of those?? It might seem odd Niclas, but I have the impression that we (the group of initial committers) felt that dropping the name Jini for a TLP was required as 'concession' to proceed with the Proposal. The response so far on Jim's 'patches' is minimal leaving us a bit in the dark I guess. I can't say I sense a form of consensus here, especially with regard to #1 and #2, so that we can resolve #3 and seek for the Sponsor to proceed (if my understanding of the process is correct). So far we have seen concerns raised with regard to Jini as project name, and there were not that many ASF people that indicated this was no problem as reaction to that. I believe there is some misunderstanding about the Jini technology here at incubator and how one should perceive our key characteristics. I can completely understand that as we've done things differently for a very long time (since 1999), those relative new in our community also often have problems grasping it completely. I believe Jim's 'patches' represent what is still acceptable by the Jini Community as we have discussed in the past and recently. We can't bend our technical foundation in a way that would be considered more mainstream, but we try to adapt in a way that meets the (as Jukka pointed out) social or perceptional characteristics of the ASF (assuming there is a single one). And, with my Jini Community Member hat on, it would be really nice if we have an indication of light at the end of the tunnel. The license change to ALv2 for the Jini Technology was one that took very long and with a huge impact for us all, this step will likely bring even more uncertainty. We have some 'turmoil' behind us. It would be nice if the Jini Community for which the ASF project is intended to be the water cooler can focus on the technical and social challenges ahead instead of waiting for what will be next. BTW it hasn't been mentioned yet but September 13, 14 we have our tenth *free* Jini Community Meeting in Brussels, see http://www.jini.org/wiki/Category:10th_Jini_Community_Meeting for more details. It is a great opportunity to learn more about the Jini Technology and our greater Community. And it would be really a joy if we could report about where the water cooler ends up ;-) -- Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Joining Incubator PMC (was Re: [VOTE] Accept Wicket into the Incubator)
On 8/24/06, Upayavira [EMAIL PROTECTED] wrote: Bertrand Delacretaz wrote: ...Not sure if binding or not, I've signed up as a mentor for Wicket but didn't participate in incubator activities before. Currently non-binding. But, as an ASF member, you should ask the Incubator PMC to join. Once you've joined, your votes will become binding. (at least that is my understanding) Ok, here it goes then: I'd like to join the incubator PMC if you guys want me. I tend to have an overstuffed schedule, so can't promise much involvement besides helping with Wicket incubation as a mentor. But I'm happy to help when I manage to find some time. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIni Proposal
Hi, On 8/22/06, Jim Hurley [EMAIL PROTECTED] wrote: We would like to include the API docs (specifications seems to be a loaded term, with many different definitions and assumptions tied up in it) in the project. OK. So the scope of a revised proposal would be broader than just the implementation of existing standards. I'd be happy with that, and even with keeping the Jini name based on the expressed views of the Jini community. The Apache Jini project would be more like the Cocoon or Lucene (just to name a few) projects that define their own interfaces than projects like Tomcat or Xerces that implement an externally defined interface. * net.jini.* -- this is the primary Jini namespace defined in the API docs, and chiefly for compatibility reasons with existing implementations and applications, we can not change this. I don't see any problem with this. * com.sun.jini.* -- there are also some compatibility issues associated with changing this namespace in the implementation, but we understand the reasons for wanting to change this to org.apache.projectname, and would do this as part of the incubation phase of the project. I think it should also be possible to place some compatibility classes in com.sun.jini.* that can either subclass or act as proxies to the respective classes in org.apache.jini.*. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Wicket into the Incubator
On 8/24/06, Upayavira [EMAIL PROTECTED] wrote: So, please cast your votes: [X] +1 Accept Wicket as an Incubator podling [ ] 0 Don't care [ ] -1 Reject this proposal for the following reason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Wicket into the Incubator
+1 On 8/24/06, Justin Erenkrantz [EMAIL PROTECTED] wrote: On 8/24/06, Upayavira [EMAIL PROTECTED] wrote: So, please cast your votes: [X] +1 Accept Wicket as an Incubator podling [ ] 0 Don't care [ ] -1 Reject this proposal for the following reason - 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]
-1 votes on proposals need no explanation was Re: [VOTE] Accept Wicket into the Incubator
On 8/24/06, Upayavira [EMAIL PROTECTED] wrote: [ ] +1 Accept Wicket as an Incubator podling [ ] 0 Don't care [ ] -1 Reject this proposal for the following reason: FYI: this is a majority vote not subject to vetos. So, there's no requirement that you provide a reason for voting against it - just like you don't have to provide a reason why you're voting for it. If you want to provide a reason, great, but I could just vote against it without further comment and that's perfectly fine too. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Wicket into the Incubator
Hi, +1. Yoav On 8/24/06, Don Brown [EMAIL PROTECTED] wrote: +1 On 8/24/06, Justin Erenkrantz [EMAIL PROTECTED] wrote: On 8/24/06, Upayavira [EMAIL PROTECTED] wrote: So, please cast your votes: [X] +1 Accept Wicket as an Incubator podling [ ] 0 Don't care [ ] -1 Reject this proposal for the following reason - 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: [VOTE] Accept Wicket into the Incubator
+1 (non-binding) On 8/24/06, Yoav Shapira [EMAIL PROTECTED] wrote: Hi, +1. Yoav On 8/24/06, Don Brown [EMAIL PROTECTED] wrote: +1 On 8/24/06, Justin Erenkrantz [EMAIL PROTECTED] wrote: On 8/24/06, Upayavira [EMAIL PROTECTED] wrote: So, please cast your votes: [X] +1 Accept Wicket as an Incubator podling [ ] 0 Don't care [ ] -1 Reject this proposal for the following reason - 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] -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PROPOSAL] InfoEng project proposal
Hi, I'm submitting this proposal because of my desire to contribute to the ASF and, especially, because the project proposed for incubation is particularly directed toward creating new tools for ASF developers to work more efficiently and derive greater rewards from their open-source work. I would really appreciate any feedback that you could provide, and if there are two (or more) developers who could contribute to this project to get to three committers, well, that would be a dream come true. ;) The fact that there is only one developer for this project is obviously in conflict with ASF incubator guidelines, but I am submitting this proposal in the hopes that it will be considered nonetheless. There is running code to build upon, with a history of consistent releases, an ongoing commitment to new development, and the intention to recruit new developers to contribute in a meritocratic process. Thanks for your consideration! J. Patrick Bedell [EMAIL PROTECTED] Copy of wikitext of http://wiki.apache.org/incubator/InfoEngProposal included here for convenience: InfoEng Proposal: = Abstract = The !InfoEng project will create software for the issuance, servicing, and exchange of digital financial instruments representing information (information currency). = Proposal = This is a proposal to create a project within the Apache Software Foundation to develop software to enable the application of economic mechanisms to the management of information. The !InfoEng project, founded in July 2004, has released software enabling users to create digital financial instruments (called information currency) representing information. The concept of representing information, as opposed to physical assets, by tradeable financial instruments is believed to be new, and has been made available without patent restrictions. The concept has been implemented in an information currency server, ICWS, and an information currency client, icsvn, both released under Apache-compatible licenses. Standardization of information currency documents and operations has been pursued by the publishing of an Internet-draft through the IETF. Software and documentation has been released at http://infoeng.sourceforge.net and http://sourceforge.net/projects/infoeng. The adoption of the !InfoEng project into the Apache Software Foundation will enable the !InfoEng project to draw upon the resources of the ASF community, which is a primary target group for which information currency systems are being developed. = Background = Open-source software can create significant economic benefits for individuals and organizations. In the market for physical goods, creators of useful products delivering economic benefits for users are incentivized by the high prices and profits that they are able to obtain from selling their goods. Unlike physical goods, digital information may be duplicated and delivered with near-zero cost, making the rationing effected by prices for physical goods less relevant for digital information. However, the prices for physical goods also signal to producers the relative importance of various commodities, and enable distributed coordination among participants in a global economy toward the satisfaction of the most-urgent needs of market participants. Economic calculation is the process by which participants in an economy use profit and loss to evaluate their prior actions and judge their future course. Methods for assessing the importance and value of information are widely used and highly useful. These methods include moderation systems (e.g. Slashdot), ranking of information by activity (ranking of downloadable files by number of downloads), and various recommendation systems, among many others. However, the mechanisms of economic calculation are not routinely applied to the valuation and management of information (although information, freely redistributable or otherwise, can significantly influence economic valuations of physical goods). There are a variety of reasons for this, but the most important is the fact that digital information may be reproduced for an infinitesimal cost relative to the cost of duplicating physical goods, making it impractical, generally, to charge for the scarce resources used to duplicate and distribute the digital information. The software released by the !InfoEng project enables the operator of an information currency server to generate from a client request digital financial instruments representing information (information currency), and to perform the network operations necessary to service the issued information currency. As a specific example, the icsvn information currency client released by the !InfoEng project is a client for the Subversion version control system which can be used to generate information currency units with each commit to a Subversion repository. The developer who has received information currency representing their contribution(s) may, if
Re: [VOTE] Accept Wicket into the Incubator
On 8/24/06, Greg Stein [EMAIL PROTECTED] wrote:
On 8/24/06, Ersin Er [EMAIL PROTECTED] wrote:
...
Wicket vs. Struts: http://www.wicket-wiki.org.uk/wiki/index.php/Struts
Bleh. That page confuses a lot of things. It conflates disparate
components (e.g. Struts and JSP) in order to form opinions.
As the note on top of the article states, it was not written by any
team member of Wicket.
If you are interested in my take amongst some other frameworks on
this, you can find it here:
http://www.virtuas.com/articles/webframework-sweetspots.html
It appears
that Wicket also does state management as a benefit which I've
rarely found to be true (any state in your http server kills
scalability).
Most competing frameworks are 'optimized' for that scalability as
their number 1 concern. That works *if* scalability is your number 1
concern, like the Googles, Amazons and other large public facing web
sites. However, if you are developing systems for just a couple of
(tens of) thousand users, where the load is predictable etc, you might
as well focus on other issues than merely scalability. Wicket focusses
first on the development model and only in the second case, as an
optimization, gives you the tools to tune your application for
scalability.
Two years ago I was looking for a framework that would scale better
for development. A framework that would let us utilize reuse like we
were used to with e.g. Swing. A framework that would save our projects
from all the hacks, ad-hock session usage etc that inevitably popped
up when the UI get more complex. A framework that would help our
junior programmers learn object orientation instead of learning just
about every bad programming habit one can image. A framework that
would allow us to hire HTML/CSS guys with their own tools for the
layout etc and leave the programming to programmers. A framework that
would have more means of breaking functionality up in smaller pieces
so that for a change we would end up with something maintainable after
spending a couple of man years building. Those were real, urgent
problems that needed to be addressed and that the (model 2) frameworks
we were using at that time didn't address (in fact they made things
worse). With Wicket I found a framework with a solution to these
problems.
On a pro, it seems to talk smack about JSP. Good. On a con, it uses a
lot of buzzwords to try to demonstrate superiority. I don't know how
Wicket is fully object-oriented. You work with hierarchies of
components and design your application as such. There is no need to
bend your oo design to fit with the request-response nature of the
HTTP protocol. will really help. The web *is* request/response.
This is akin to the objections people up to today make to ORM
frameworks like Hibernate. They say you shouldn't try to bend OO
design to fit the relational nature of databases. In this case too,
it's a matter of optimization; staying close to the metal gives you
the best options to optimize, but using an ORM framework or component
framework provides you with a superior programming model.
I'm sad people feel we are trying to sell Wicket with a bunch of buzz
words. We hoped we were doing better than that, and in fact feel that
by swimming against the current in many areas, going for the cheap
sell is the last thing we did. Anyway, the 'OO programming model' part
is really important to us. The framework was started by Jonathan
(previously worked for Microsoft as a Java evangelist, worked amongst
other things Visual J++, switched to SUN to work on AWT and Swing)
who, when starting out for his first web application with Java, was
appalled by the fact that there was no framework, out of all the 50 or
so he found, that allowed him to just simply program like he could do
with Swing. JSF, Echo and Tapestry came close to his goals as at least
they know component reuse and state management, but he still missed
the 'simply Java' part. So he decided to scratch his own itch and
created Wicket.
With object oriented programming we mean something simple really, like:
public class MyComponent extends SomeOtherComponent { ...
or
public class ClickPanel extends Panel {
private int count = 0;
public ClickPanel(MarkupContainer parent, String id) {
Link l = new Link(this, link) {
public void onClick() {
count++;
}
};
new Label(l, label, new PropertyModel(this, count));
}
That's all you have to do to create a new component, and if it is
available in your class path, it's available for use with no other
requirements. Personally, I favor this way of programming over having
to be aware of the underlying protocol all the time, just as I would
favor not to bother with the event loop of the operating system when
I'm developing a desktop application. You can object to the importance
we give to providing a clean OO model, and argue that our tradeoffs
are ill chosen, but I believe Wicket fills a gap in the web framework
sphere.
Eelco
Re: [VOTE] Accept Wicket into the Incubator
On 8/24/06, Eelco Hillenius [EMAIL PROTECTED] wrote: ... I'm developing a desktop application. You can object to the importance we give to providing a clean OO model, and argue that our tradeoffs are ill chosen, but I believe Wicket fills a gap in the web framework sphere. I didn't object... I voted -0 based on the information I was pointed out, which (as you said) is not a very good comparison point. *shrug* Cheers, -g -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Wicket into the Incubator
I didn't object... I voted -0 based on the information I was pointed out, which (as you said) is not a very good comparison point. *shrug* Sorry if I came across too strongly. Igor pointed out my reply had a bit of a zealous tone to it. My only goal was to explain the idea behind Wicket a bit. :) Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Wicket into the Incubator
Upayavira wrote: [X] +1 Accept Wicket as an Incubator podling +1, non-binding Ross - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal for a new incubation project: Unstructured Information Management Architecture - UIMA - project descriptions
The Unstructured Information Management Architecture (UIMA) is an architecture and software framework for creating, discovering, composing and deploying a broad range of multi-modal analysis capabilities. We propose a project to develop, implement, support and enhance UIMA framework implementations that comply with the UIMA standard (being put forward concurrently for standardization within OASIS http://www.oasis-open.org - not yet submitted, but we plan to do this early in September.). What is a a framework for multi-modal analysis capabilities? Something I would find helpful for all projects in the Apache Software Foundation is that they have some sort of highly visible/easily available description of what they are in terms that are clear to a user who may not be versed in the particular technology of the specific codebase. To be fair, there are other projects already present in the foundation that arent' as clear as they could be (one common irritant is implementation of JSR blah blah without an explanation of what that is or what it's good for, or a direct link to that explanation), so I'm just using this as an opportunity to speak up, rather than citing this as some sort of egregious violator of this principle. Motivation for UIMA: Databases are core components of nearly all applications; they store information in structured tables. But more and more of the available digital data is unstructured (e.g. email, web documents, images, audio clips, video streams) with little information (metadata) attached to explain its content or context. Although many applications have been built to process unstructured data, they have either managed it as a BLOB or they have developed isolated applications for analyzing the content. In the absence of a standardized means for analytical applications to share insights extracted from the content, analytical applications cannot build upon one another. As a result, the industry has barely begun to tap the value locked in unstructured information. Aha... I think this starts to get at what I want to know. Personally, were I writing this, I might consider puting this at or near the top for the benefit of those who don't immediately recognize what the software does. It sounds potentially useful once I read the above. UIMA was built to help developers create solutions that get more value from unstructured information more quickly and at lower cost by making it easy to reuse and combine analytic modules from different sources into new analytic applications. The architecture and the framework have been validated through work with USA's DARPA which is using it as a standard for key projects Some sort of example of what they've done wouldn't be bad either, but that's just nitpicking. Thankyou, -- David N. Welton - http://www.dedasys.com/davidw/ Linux, Open Source Consulting - http://www.dedasys.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PROPOSAL] Fluoride
Fluoride, a Feed Server Proposal 0. Rationale a RSS/Atom feed by default is hard to track. The aim of this proposal is to create a server which can track statistics on who is reading your feeds, and what they are reading. 0.1 Criteria Meritocracy: Apache was chosen for an incubator for the guidance the community can provide. Community: None yet.. this is just an idea Core Developers: Ian Holsman. ASF Member Alignment: The initial code is planed to be implemented in C and python, but I am inpartial. I'm OK with java as well. 0.2 Warning signs Orphaned products: N/A Inexperience with open source: Ian is a ASF member Homogenous developers: Only one developer. I am hoping for others to be interested and join in Reliance on salaried developers: No. No ties to other Apache products: It is planned to use mod_python Apache Httpd as a platform. A fascination with the Apache brand: we are fascinated by it. It's shiny. Seriously I chose apache as I thought others may be interested 1. Scope of the subprojects The initial scope of the project will be the development of a functionally-complete implementation of a server capable of handling between 10-1000 unique feeds with each feed having multiple subscribers. 2. Initial source None. 2.1 External Dependencies of the project The current implemenation depends on the following components: It is envisioned that the project would require Django for it's maintenance screens, and use Apache's Httpd and mod_python. 3. Identify the ASF resources to be created 3.1 mailing list(s) fluoride-ppmc (moderated subscriptions) fluoride-dev fluoride-commits fluoride-user 3.2 Subversion repository https://svn.apache.org/repos/asf/incubator/fluoride 3.3 Bugzilla fluoride 4. Identify the initial set of committers: Ian Holsman (Zilbo) 5. Identify Apache sponsoring individual We request that the Apache Incubator PMC sponsor the Abdera Atom implementation as an incubating project. Champion: TBD Mentors: TBD -- Ian Holsman [EMAIL PROTECTED] http://garden-gossip.com/ -- what's in your garden? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Fluoride
this is a dupe. I sent it from my apache.org address initially which wasn't subscribed. I did forget to mention the wiki page: http://wiki.apache.org/ incubator/FluorideProposal in the original too. On 24/08/2006, at 6:59 AM, Ian Holsman wrote: Fluoride, a Feed Server Proposal 0. Rationale a RSS/Atom feed by default is hard to track. The aim of this proposal is to create a server which can track statistics on who is reading your feeds, and what they are reading. 0.1 Criteria Meritocracy: Apache was chosen for an incubator for the guidance the community can provide. Community: None yet.. this is just an idea Core Developers: Ian Holsman. ASF Member Alignment: The initial code is planed to be implemented in C and python, but I am inpartial. I'm OK with java as well. 0.2 Warning signs Orphaned products: N/A Inexperience with open source: Ian is a ASF member Homogenous developers: Only one developer. I am hoping for others to be interested and join in Reliance on salaried developers: No. No ties to other Apache products: It is planned to use mod_python Apache Httpd as a platform. A fascination with the Apache brand: we are fascinated by it. It's shiny. Seriously I chose apache as I thought others may be interested 1. Scope of the subprojects The initial scope of the project will be the development of a functionally-complete implementation of a server capable of handling between 10-1000 unique feeds with each feed having multiple subscribers. 2. Initial source None. 2.1 External Dependencies of the project The current implemenation depends on the following components: It is envisioned that the project would require Django for it's maintenance screens, and use Apache's Httpd and mod_python. 3. Identify the ASF resources to be created 3.1 mailing list(s) fluoride-ppmc (moderated subscriptions) fluoride-dev fluoride-commits fluoride-user 3.2 Subversion repository https://svn.apache.org/repos/asf/incubator/fluoride 3.3 Bugzilla fluoride 4. Identify the initial set of committers: Ian Holsman (Zilbo) 5. Identify Apache sponsoring individual We request that the Apache Incubator PMC sponsor the Abdera Atom implementation as an incubating project. Champion: TBD Mentors: TBD -- Ian Holsman [EMAIL PROTECTED] http://garden-gossip.com/ -- what's in your garden? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ian Holsman [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: -1 votes on proposals need no explanation was Re: [VOTE] Accept Wicket into the Incubator
Justin Erenkrantz wrote: On 8/24/06, Upayavira [EMAIL PROTECTED] wrote: [ ] +1 Accept Wicket as an Incubator podling [ ] 0 Don't care [ ] -1 Reject this proposal for the following reason: FYI: this is a majority vote not subject to vetos. So, there's no requirement that you provide a reason for voting against it - just like you don't have to provide a reason why you're voting for it. If you want to provide a reason, great, but I could just vote against it without further comment and that's perfectly fine too. -- justin Okay. Thanks for the clarification. I'll try to remember that for the next podling I propose :-) Regards, Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] InfoEng -- http://wiki.apache.org/incubator/InfoEngProposal
Hi. on the initial read, I wasn't exactly sure what it was this service was doing. although I think I know what a financial instrument is, I've usually only seen them applied to their regular things.. stocks, bonds, futures, options, etc... not information. so I was a bit confused.. who exactly would use this? (a company name would be great here if there is one) and an example of what would be traded.. (are you talking something like DRM here?) Is this software to trade property rights? or to buy futures on a income stream on a piece of information? regards Ian -- Ian Holsman [EMAIL PROTECTED] http://med-chatter.com/ it's about the medicine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: -1 votes on proposals need no explanation was Re: [VOTE] Accept Wicket into the Incubator
Upayavira wrote: Justin Erenkrantz wrote: FYI: this is a majority vote not subject to vetos. So, there's no requirement that you provide a reason for voting against it - just like you don't have to provide a reason why you're voting for it. If you want to provide a reason, great, but I could just vote against it without further comment and that's perfectly fine too. -- justin Okay. Thanks for the clarification. I'll try to remember that for the next podling I propose :-) Although... an explanation can go a long way to have other pmc members consider the issues, good and bad, that they might have overlooked. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] InfoEng -- http://wiki.apache.org/incubator/InfoEngProposal
Hi Ian, Thanks for your reply. In brief, the answer to your final question is that information currency is a representation of property rights to the underlying information. However, information currency is not designed to restrict the distribution of the underlying information in any way - it is simply necessary for the information currency units ( each of a form like icu sidhttps://leucine.infoeng.org:48443/icws/seriesInfo?seriesID=b5fe373fb6aab8ba6bad6fb933df1934c7740956/sid ciQjWragyHoQstn8IggdB5WKASAJi8weg/cjINg1Ugw6GpsVWSakSTDzX/y1jW20uEfG9btHQwTuP5 0+G33f46BsPMgVV9Sho1kzoRW4pRFFaShVgO7PL63Tz4AbB/BIrj1KKFL60T+wijvmVA8fZChzGo x7Z9np2WEOjTBS2iC7I=/ci sigim1KV5cwk2Gj5YjeDTSZVgZy3evHGTcMXDJ8zrdsvlV/FGMUjFYED2bHSe7lUlV9KSbdnTbR5VFR IsYGWR87VK1060yUT8K+PU1n1s/+XN2DeLom8aIrq+jxmIyQ9vo0oL6500FYBUSUhTCZb/LxMZQp QL1dqs2x9+bmR4am1gYbYQfJD4eiaYnMxEnW3PDR1bqwz8deoAPT1BgL2lZNcdTnrrjsmGLbbAtm QST0nAx2+e4okFGCOfJiM0NKALTtLc4kDFMTaJKDqRRcrJrLm2A+hEy13eaGXTIyqsuleN0Qo/T5 2+I1+C48sO2avDUaBvfgYP40ph2Hg4oEiAmByQ==/sig /icu ) to be kept secret until the ICU is transferred in an exchange. The sid element contains a URL for obtaining the underlying information - there's a longer description in the I-D at http://infoeng.sourceforge.net/information-currency-rfc.txt. I believe that the idea of representing information with financial instruments is new, which is why I have explicitly disclaimed patent rights in my proposal (and on infoeng.sourceforge.net, for over a year). The software that I've released makes it possible for a server operator to allow clients to create financial instruments representing the information created by the clients. The clients holding information currency can then trade it in a way that is similar to other financial instruments, without necessarily restricting the use of the underlying information in any way. This work is an effort to implement a software invention that, I hope, will benefit open-source developers. The company that would operate the ICWS server (or, realistically, a future production-quality information currency server) would play a role like the underwriter of stocks. However, instead of property titles to a company providing legal rights to the physical property of the company, information currency is a property title to an individual unit of information, which does not by itself grant any rights or impose any restrictions on the use of that information. A primary user scenario is where the developer of open-source code gets (for example) 100 information currency units for each of their commits to a Subversion repository using icsvn. Each set of ICUs is distinct, representing the specific commit that was used to generate the IC series. Then, if a user of the software wishes, they can purchase the information currency units corresponding to a particularly valuable unit of information, making it possible to compensate developers in a new way. There is no guarantee that the server is authoritative or trustworthy, or that the commits aren't simply garbage - but financial markets for information currency will, I'm sure, handle these issues properly. Eventually, it will be possible to consult prices for the information currency associated with specific units of software to determine the value of that underlying software. Essentially, this is software to allow a server to maintain tradeable property rights that are held (initially) by the creators of information. The property rights do not inherently restrict use or redistribution, and are not intended to, but simply make it possible to manage information in a new way that is under development. I hope this helps. Thanks again for your feedback - I really appreciate it! J. Patrick Bedell [EMAIL PROTECTED] On 8/24/06, Ian Holsman [EMAIL PROTECTED] wrote: Hi. on the initial read, I wasn't exactly sure what it was this service was doing. although I think I know what a financial instrument is, I've usually only seen them applied to their regular things.. stocks, bonds, futures, options, etc... not information. so I was a bit confused.. who exactly would use this? (a company name would be great here if there is one) and an example of what would be traded.. (are you talking something like DRM here?) Is this software to trade property rights? or to buy futures on a income stream on a piece of information? regards Ian -- Ian Holsman [EMAIL PROTECTED] http://med-chatter.com/ it's about the medicine - 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]
