Re: Name change from Lucene Connectors Framework to Apache Connectors Framework
On Aug 25, 2010, at 10:26 AM, Upayavira wrote: On Wed, 2010-08-25 at 09:50 -0400, Grant Ingersoll wrote: So, how does this get resolved? Shall I call a formal vote for the IPMC? I rather like the name, but (somewhat) understand the objections. That being said, I'm not all that clever at naming, so... You rather like which name?? ACF My take: 1. come up with a name. 2. check for exixting uses of that name 3. if it passes #2 then get support of your PPMC 4. Propose it to IPMC. 5. Vote on the IPMC about the name. If you want, you can add #4a: discuss with IPMC whether a vote is really required for this, in which case you might be able to skip #5, but that process would probably be slower in the end! Well, I would argue we did all that, with the exception of a formal IPMC vote (although we did ask here). It seemed to pass muster until a week later, a fair amount of time after we went and made the changes. Upayavira On Aug 25, 2010, at 7:42 AM, Upayavira wrote: On Wed, 2010-08-25 at 06:49 -0400, Grant Ingersoll wrote: Sure would have been nice if these objections (other than David's) would have been brought up last week before we went and changed everything (after waiting several days for feedback) b/c we were working under the assumption that no one thought it was a problem. At any rate, we'll go discuss. I apologise for that. Unfortunately it was (for me) one of those situations when it takes a resonable volume of mail before it attracts my attention enough to read what is being said. Upayavira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Grant Ingersoll http://lucenerevolution.org Lucene/Solr Conference, Boston Oct 7-8 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Name change from Lucene Connectors Framework to Apache Connectors Framework
On Thu, 2010-08-26 at 06:41 -0400, Grant Ingersoll wrote: On Aug 25, 2010, at 10:26 AM, Upayavira wrote: On Wed, 2010-08-25 at 09:50 -0400, Grant Ingersoll wrote: So, how does this get resolved? Shall I call a formal vote for the IPMC? I rather like the name, but (somewhat) understand the objections. That being said, I'm not all that clever at naming, so... You rather like which name?? ACF My take: 1. come up with a name. 2. check for exixting uses of that name 3. if it passes #2 then get support of your PPMC 4. Propose it to IPMC. 5. Vote on the IPMC about the name. If you want, you can add #4a: discuss with IPMC whether a vote is really required for this, in which case you might be able to skip #5, but that process would probably be slower in the end! Well, I would argue we did all that, with the exception of a formal IPMC vote (although we did ask here). It seemed to pass muster until a week later, a fair amount of time after we went and made the changes. Sure. I recognise I'm coming in late with my concerns. I personally don't like it as a name, as it is a descriptive style name that could be misleading, but at this point I'm not going to stand in its way. Upayavira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Name change from Lucene Connectors Framework to Apache Connectors Framework
On Aug 26, 2010, at 3:41 AM, Grant Ingersoll wrote: On Aug 25, 2010, at 10:26 AM, Upayavira wrote: On Wed, 2010-08-25 at 09:50 -0400, Grant Ingersoll wrote: So, how does this get resolved? Shall I call a formal vote for the IPMC? I rather like the name, but (somewhat) understand the objections. That being said, I'm not all that clever at naming, so... You rather like which name?? ACF My take: 1. come up with a name. 2. check for exixting uses of that name 3. if it passes #2 then get support of your PPMC 4. Propose it to IPMC. 5. Vote on the IPMC about the name. If you want, you can add #4a: discuss with IPMC whether a vote is really required for this, in which case you might be able to skip #5, but that process would probably be slower in the end! Well, I would argue we did all that, with the exception of a formal IPMC vote (although we did ask here). It seemed to pass muster until a week later, a fair amount of time after we went and made the changes. I responded within 5 hours of the proposal. AFAICT the PPMC members have not responded to that post at all. thanks david jencks Upayavira On Aug 25, 2010, at 7:42 AM, Upayavira wrote: On Wed, 2010-08-25 at 06:49 -0400, Grant Ingersoll wrote: Sure would have been nice if these objections (other than David's) would have been brought up last week before we went and changed everything (after waiting several days for feedback) b/c we were working under the assumption that no one thought it was a problem. At any rate, we'll go discuss. I apologise for that. Unfortunately it was (for me) one of those situations when it takes a resonable volume of mail before it attracts my attention enough to read what is being said. Upayavira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Grant Ingersoll http://lucenerevolution.org Lucene/Solr Conference, Boston Oct 7-8 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] ALOIS to enter the incubator
Hi, I would like to call a vote for accepting ALOIS for incubation in the Apache Incubator. The full proposal is available below and on the proposal wiki page (http://wiki.apache.org/incubator/AloisProposal). We ask the Incubator PMC to sponsor it, with Scott Deboy volunteering as Champion and Mentor. Additional mentors are warmly welcome. Please cast your vote: [ ] +1, bring ALOIS into Incubator [ ] +0, I don't care either way, [ ] -1, do not bring ALOIS into Incubator, because... This vote will be open for 72 hours and only votes from the Incubator PMC are binding. Thanks, Urs = Preface = ALOIS is a log collection and correlation software with reporting and alarming functionalities. It has been implemented by the Swiss company IMSEC for a customer about five years ago. GPL-licenced, implemented in Ruby and completely based on other OSS-licensed components, it was designed for the open source community right from the start. Now that the software has shown its functioning over several years in production with the one customer and one IMSEC-internal installation, it seems to be the right time to open it to a wider community. = Abstract = ALOIS stands for „Advanced Logging and Intrusion Detection System“ and is meant to be a fully implemented open source SIEM (security information and event management) system. = Proposal = While almost all other SIEM software, be it closed or open source, concentrate on the technological part of security monitoring, ALOIS is aimed to monitor the security of the content. It intends to be pro-active in the detection of potential loss, theft, mistaken modification or unauthorized access. ALOIS works on log messages and thus contains all the basic functionality of a conventional SIEM, as centralized collecting, normalizing, aggregation, analyzing and correlating of all log messages, as well as reporting all security related events. Therefore it can be used as any other SIEM. ALOIS consists of five modules interacting to ensure a scaleable functionality of a SIEM: * Insink is the message sink, which is the receiving entry point for all the different log messages into ALOIS. It is partly based on the syslog-ng software. Insink listens for messages (UDP), waits for messages (TCP), receives message collections (files, emails) and pre-filters them to prevent from message flow overload. * Pumpy is the incoming FIFO buffer, implemented as a relational database tables. which contain the incoming original messages (in raw format). In a complex system setup, there may be several insink instances, e.g. for a group of hosts, for specific types of messages, or for high-avaliablity. * Prisma contains logic to split up the text of log messages into separate fields, based on regular expressions. Actually, prisma is a set of prismi, each one prisma for one type of log message (apache, cisco etc. Several prismi can be applied to the same message. This allows for stacked messages, i.e. forwarded log messages contained in compressed files contained in e-mail messages. The data retrieved form the log messages is stored in a database called Dobby. Due to prisma being written in Ruby, prismi can be applied interactively (when having system access). * Dobby is the central log database. It should be separated from the Pumpy database for availability and performance reasons. The current implementation is based on MySQL. * The Analyzer contains the two sub-systems Lizard and Reptor. Lizard is the analysis engine and user interface of ALOIS, implemented in Ruby on Rails using AJAX. It allows for interactive browsing through the collected data, exclusion/inclusion/selection of data, data sorting, data filtering, creation of views, ad-hoc textual and graphical reporting. Reptor allows for automatic activation of views and comparison of these views' results to a predefined result (pattern matching). In case of mismatch, Reptor sends the result to predefined e-mail addresses. Its modular design guarantees ALOIS to scale from little to large organizations. Since there exists a Debian package, it's easy to build a test system or even a productive system for small environments. Although the software has been in productive use for a few years, there is still a lot of desired functionality missing. The plugability of new connected systems is given, but needs some revision. It is a given goal of the project to allow modules in other programming language. Furthermore, it has been discussed if parts of the existing implementation may be replaced with other proven open source software, e.g. the correlation engine or the web frontend. The other way round, it has been discussed that the filter creation engine would make a good tool for any kind of structured data, and thus could be separated from ALOIS and standardized as a stand-alone tool. = Background = It's not simple to know what happens in a bigger
Re: [PROPOSAL] Apache Isis
Hi Dan, +1 (non-binding) Cheers, Siegfried Goeschl On 24.08.10 19:12, Dan Haywood wrote: I'd like to formally propose a new project for the incubator, Apache Isis. If accepted, Isis will combine the existing open source Naked Objects framework with a collection of sister projects, providing an extensible Java-based framework for rapidly developing domain-driven applications. I floated the idea of Isis on this mailing list about a month or so ago, and we got some positive feedback and a couple of expressions of interest in contributing. Since then, we've put together a proposal (also copied in below) onto the incubator wiki. The proposal is at: http://wiki.apache.org/incubator/IsisProposal. The current codebase is at: http://nakedobjects.org, with sister projects hosted at: http://starobjects.org We currently have two mentors, but require more, and we still need a champion. I'm hoping that this post will generate some further interest to develop the proposal further. All being well we hope to put this proposal to a vote in a week or two's time. Thanks for reading, looking forward to your feedback. Dan Haywood ~~~ = Isis Proposal = The following presents the proposal for creating a new project within the Apache Software Foundation called Isis. == Abstract == Isis will be an extensible standards-based framework to rapidly develop and enterprise level deploy domain-driven (DDD) applications. == Proposal == The Isis project will bring together a collection of open source projects that collectively support the rapid development of domain-driven applications. The heart of Isis is the Naked Objects Framework, an established open source project that has been around since 2002. In addition, it will incorporate a number of sister projects that build on Naked Objects' pluggable architecture and which extend the reach of Naked Objects in several key areas. In addition, the project will be reorganising the existing projects to logically separate out the components into [[http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/|JSR-299]] beans. We believe that the JSR-299 programming model is likely to become widely used for enterprise Java applications; adopting it should make it easier for new contributors to understand how the framework fits together and therefore to develop their own extensions. In turn, we hope this will further extend the reach of the framework to other complementary open source frameworks (either within Apache or outside of it). == Background == Naked Objects is an open source Java framework that was originally developed to explore the idea of enterprise systems that treat the user as a problem solver, not a process follower. Conceived by Richard Pawson, the first version of the framework was written by Robert Matthews (2002). Richard and Rob also wrote a book, Naked Objects (Wiley, 2002), to explain the idea. More generally, Naked Objects is an implementation of the naked objects architectural pattern. In its purest form, all the developer has to do is develop their domain model as pojos; Naked Objects then provides: a object-oriented user interface by rendering those pojos; persistence by extracting the content of the pojos; security by wrapping access to the pojos; remoting by turning local calls into remote ones; and localisation by adapting all the names used in the metamodel. All of this is done reflectively at runtime so that the developer can concentrate on the most important aspect - the application itself. You can think of Naked Objects' OOUI generation as analogous to Hibernate and other ORMs, but rather than reflecting the pojo into the persistence layer, they are reflected into the presentation layer. A number of other open source frameworks cite it as their inspiration, including [[http://jmatter.org|JMatter]], [[http://openxava.org|OpenXava]], and [[http://www.trailsframework.org|Trails]]. Over this time Naked Objects has attracted a fair degree of attention among the early adopter crowd, generally splitting opinion as either a very good idea or a very bad one. A common misconception is that naked objects is only appropriate for simple CRUD based applications. While developing CRUD applications is indeed trivial, an important innovation is that the UI generated by NO also renders the pojo's commands/behaviors (we call them actions). Simply stated: any public method that does not represent a property or collection is rendered so it can be invoked, eg with a button, a menu item or a hyperlink. We characterize entities with such behaviors as behaviorally complete. It's OO as your mother taught it to you. At the same time that we have been developing our ideas on the naked objects, there has been a resurgent interest in object modelling at the enterprise level, specifically as described by Eric Evans' book, [[http://domaindrivendesign.org/books|Domain Driven Design]]. Recognizing that there's a lot of
Re: [VOTE] ALOIS to enter the incubator
I don't see anything explicit in here about relicensing from GPL to ASL. Perhaps that was hashed out before I joined the PMC? I'm +0 tending toward -1 without an explicit statement that the copyright owners are known and on board with the license change. On Thu, Aug 26, 2010 at 12:09 PM, Urs Lerch m...@ulerch.net wrote: Hi, I would like to call a vote for accepting ALOIS for incubation in the Apache Incubator. The full proposal is available below and on the proposal wiki page (http://wiki.apache.org/incubator/AloisProposal). We ask the Incubator PMC to sponsor it, with Scott Deboy volunteering as Champion and Mentor. Additional mentors are warmly welcome. Please cast your vote: [ ] +1, bring ALOIS into Incubator [ ] +0, I don't care either way, [ ] -1, do not bring ALOIS into Incubator, because... This vote will be open for 72 hours and only votes from the Incubator PMC are binding. Thanks, Urs = Preface = ALOIS is a log collection and correlation software with reporting and alarming functionalities. It has been implemented by the Swiss company IMSEC for a customer about five years ago. GPL-licenced, implemented in Ruby and completely based on other OSS-licensed components, it was designed for the open source community right from the start. Now that the software has shown its functioning over several years in production with the one customer and one IMSEC-internal installation, it seems to be the right time to open it to a wider community. = Abstract = ALOIS stands for „Advanced Logging and Intrusion Detection System“ and is meant to be a fully implemented open source SIEM (security information and event management) system. = Proposal = While almost all other SIEM software, be it closed or open source, concentrate on the technological part of security monitoring, ALOIS is aimed to monitor the security of the content. It intends to be pro-active in the detection of potential loss, theft, mistaken modification or unauthorized access. ALOIS works on log messages and thus contains all the basic functionality of a conventional SIEM, as centralized collecting, normalizing, aggregation, analyzing and correlating of all log messages, as well as reporting all security related events. Therefore it can be used as any other SIEM. ALOIS consists of five modules interacting to ensure a scaleable functionality of a SIEM: * Insink is the message sink, which is the receiving entry point for all the different log messages into ALOIS. It is partly based on the syslog-ng software. Insink listens for messages (UDP), waits for messages (TCP), receives message collections (files, emails) and pre-filters them to prevent from message flow overload. * Pumpy is the incoming FIFO buffer, implemented as a relational database tables. which contain the incoming original messages (in raw format). In a complex system setup, there may be several insink instances, e.g. for a group of hosts, for specific types of messages, or for high-avaliablity. * Prisma contains logic to split up the text of log messages into separate fields, based on regular expressions. Actually, prisma is a set of prismi, each one prisma for one type of log message (apache, cisco etc. Several prismi can be applied to the same message. This allows for stacked messages, i.e. forwarded log messages contained in compressed files contained in e-mail messages. The data retrieved form the log messages is stored in a database called Dobby. Due to prisma being written in Ruby, prismi can be applied interactively (when having system access). * Dobby is the central log database. It should be separated from the Pumpy database for availability and performance reasons. The current implementation is based on MySQL. * The Analyzer contains the two sub-systems Lizard and Reptor. Lizard is the analysis engine and user interface of ALOIS, implemented in Ruby on Rails using AJAX. It allows for interactive browsing through the collected data, exclusion/inclusion/selection of data, data sorting, data filtering, creation of views, ad-hoc textual and graphical reporting. Reptor allows for automatic activation of views and comparison of these views' results to a predefined result (pattern matching). In case of mismatch, Reptor sends the result to predefined e-mail addresses. Its modular design guarantees ALOIS to scale from little to large organizations. Since there exists a Debian package, it's easy to build a test system or even a productive system for small environments. Although the software has been in productive use for a few years, there is still a lot of desired functionality missing. The plugability of new connected systems is given, but needs some revision. It is a given goal of the project to allow modules in other programming language. Furthermore, it has been discussed if parts of the existing implementation may be replaced
Re: [PROPOSAL] Apache Isis
+1, binding. On Thu, Aug 26, 2010 at 12:12 PM, Siegfried Goeschl siegfried.goes...@it20one.at wrote: Hi Dan, +1 (non-binding) Cheers, Siegfried Goeschl On 24.08.10 19:12, Dan Haywood wrote: I'd like to formally propose a new project for the incubator, Apache Isis. If accepted, Isis will combine the existing open source Naked Objects framework with a collection of sister projects, providing an extensible Java-based framework for rapidly developing domain-driven applications. I floated the idea of Isis on this mailing list about a month or so ago, and we got some positive feedback and a couple of expressions of interest in contributing. Since then, we've put together a proposal (also copied in below) onto the incubator wiki. The proposal is at: http://wiki.apache.org/incubator/IsisProposal. The current codebase is at: http://nakedobjects.org, with sister projects hosted at: http://starobjects.org We currently have two mentors, but require more, and we still need a champion. I'm hoping that this post will generate some further interest to develop the proposal further. All being well we hope to put this proposal to a vote in a week or two's time. Thanks for reading, looking forward to your feedback. Dan Haywood ~~~ = Isis Proposal = The following presents the proposal for creating a new project within the Apache Software Foundation called Isis. == Abstract == Isis will be an extensible standards-based framework to rapidly develop and enterprise level deploy domain-driven (DDD) applications. == Proposal == The Isis project will bring together a collection of open source projects that collectively support the rapid development of domain-driven applications. The heart of Isis is the Naked Objects Framework, an established open source project that has been around since 2002. In addition, it will incorporate a number of sister projects that build on Naked Objects' pluggable architecture and which extend the reach of Naked Objects in several key areas. In addition, the project will be reorganising the existing projects to logically separate out the components into [[http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/|JSR-299]] beans. We believe that the JSR-299 programming model is likely to become widely used for enterprise Java applications; adopting it should make it easier for new contributors to understand how the framework fits together and therefore to develop their own extensions. In turn, we hope this will further extend the reach of the framework to other complementary open source frameworks (either within Apache or outside of it). == Background == Naked Objects is an open source Java framework that was originally developed to explore the idea of enterprise systems that treat the user as a problem solver, not a process follower. Conceived by Richard Pawson, the first version of the framework was written by Robert Matthews (2002). Richard and Rob also wrote a book, Naked Objects (Wiley, 2002), to explain the idea. More generally, Naked Objects is an implementation of the naked objects architectural pattern. In its purest form, all the developer has to do is develop their domain model as pojos; Naked Objects then provides: a object-oriented user interface by rendering those pojos; persistence by extracting the content of the pojos; security by wrapping access to the pojos; remoting by turning local calls into remote ones; and localisation by adapting all the names used in the metamodel. All of this is done reflectively at runtime so that the developer can concentrate on the most important aspect - the application itself. You can think of Naked Objects' OOUI generation as analogous to Hibernate and other ORMs, but rather than reflecting the pojo into the persistence layer, they are reflected into the presentation layer. A number of other open source frameworks cite it as their inspiration, including [[http://jmatter.org|JMatter]], [[http://openxava.org|OpenXava]], and [[http://www.trailsframework.org|Trails]]. Over this time Naked Objects has attracted a fair degree of attention among the early adopter crowd, generally splitting opinion as either a very good idea or a very bad one. A common misconception is that naked objects is only appropriate for simple CRUD based applications. While developing CRUD applications is indeed trivial, an important innovation is that the UI generated by NO also renders the pojo's commands/behaviors (we call them actions). Simply stated: any public method that does not represent a property or collection is rendered so it can be invoked, eg with a button, a menu item or a hyperlink. We characterize entities with such behaviors as behaviorally complete. It's OO as your mother taught it to you. At the same time that we have been developing our ideas on the naked objects, there has been a resurgent interest in object
Re: [PROPOSAL] Apache Isis
+1 (binding) On Thu, Aug 26, 2010 at 6:23 PM, Benson Margulies bimargul...@gmail.com wrote: +1, binding. On Thu, Aug 26, 2010 at 12:12 PM, Siegfried Goeschl siegfried.goes...@it20one.at wrote: Hi Dan, +1 (non-binding) Cheers, Siegfried Goeschl On 24.08.10 19:12, Dan Haywood wrote: I'd like to formally propose a new project for the incubator, Apache Isis. If accepted, Isis will combine the existing open source Naked Objects framework with a collection of sister projects, providing an extensible Java-based framework for rapidly developing domain-driven applications. I floated the idea of Isis on this mailing list about a month or so ago, and we got some positive feedback and a couple of expressions of interest in contributing. Since then, we've put together a proposal (also copied in below) onto the incubator wiki. The proposal is at: http://wiki.apache.org/incubator/IsisProposal. The current codebase is at: http://nakedobjects.org, with sister projects hosted at: http://starobjects.org We currently have two mentors, but require more, and we still need a champion. I'm hoping that this post will generate some further interest to develop the proposal further. All being well we hope to put this proposal to a vote in a week or two's time. Thanks for reading, looking forward to your feedback. Dan Haywood ~~~ = Isis Proposal = The following presents the proposal for creating a new project within the Apache Software Foundation called Isis. == Abstract == Isis will be an extensible standards-based framework to rapidly develop and enterprise level deploy domain-driven (DDD) applications. == Proposal == The Isis project will bring together a collection of open source projects that collectively support the rapid development of domain-driven applications. The heart of Isis is the Naked Objects Framework, an established open source project that has been around since 2002. In addition, it will incorporate a number of sister projects that build on Naked Objects' pluggable architecture and which extend the reach of Naked Objects in several key areas. In addition, the project will be reorganising the existing projects to logically separate out the components into [[http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/|JSR-299]] beans. We believe that the JSR-299 programming model is likely to become widely used for enterprise Java applications; adopting it should make it easier for new contributors to understand how the framework fits together and therefore to develop their own extensions. In turn, we hope this will further extend the reach of the framework to other complementary open source frameworks (either within Apache or outside of it). == Background == Naked Objects is an open source Java framework that was originally developed to explore the idea of enterprise systems that treat the user as a problem solver, not a process follower. Conceived by Richard Pawson, the first version of the framework was written by Robert Matthews (2002). Richard and Rob also wrote a book, Naked Objects (Wiley, 2002), to explain the idea. More generally, Naked Objects is an implementation of the naked objects architectural pattern. In its purest form, all the developer has to do is develop their domain model as pojos; Naked Objects then provides: a object-oriented user interface by rendering those pojos; persistence by extracting the content of the pojos; security by wrapping access to the pojos; remoting by turning local calls into remote ones; and localisation by adapting all the names used in the metamodel. All of this is done reflectively at runtime so that the developer can concentrate on the most important aspect - the application itself. You can think of Naked Objects' OOUI generation as analogous to Hibernate and other ORMs, but rather than reflecting the pojo into the persistence layer, they are reflected into the presentation layer. A number of other open source frameworks cite it as their inspiration, including [[http://jmatter.org|JMatter]], [[http://openxava.org|OpenXava]], and [[http://www.trailsframework.org|Trails]]. Over this time Naked Objects has attracted a fair degree of attention among the early adopter crowd, generally splitting opinion as either a very good idea or a very bad one. A common misconception is that naked objects is only appropriate for simple CRUD based applications. While developing CRUD applications is indeed trivial, an important innovation is that the UI generated by NO also renders the pojo's commands/behaviors (we call them actions). Simply stated: any public method that does not represent a property or collection is rendered so it can be invoked, eg with a button, a menu item or a hyperlink. We characterize entities with such behaviors as behaviorally complete. It's OO as your mother taught it to you. At the same time that we
Re: [VOTE] ALOIS to enter the incubator
Hi There is, at least in my opinion, a very clear statement regarding the licencing: = Source and Intellectual Property Submission Plan = ALOIS is currently under a GPL licence. Since there are only two contributors so far, both from the same company, there is no problem to re-licence the code and contribute it to Apache. The commitment of the company's owner has been granted. The names of the two contributors are listed elsewhere in the proposal. Do you think that ain't enough? Best Urs Am Donnerstag, den 26.08.2010, 12:17 -0400 schrieb Benson Margulies: I don't see anything explicit in here about relicensing from GPL to ASL. Perhaps that was hashed out before I joined the PMC? I'm +0 tending toward -1 without an explicit statement that the copyright owners are known and on board with the license change. On Thu, Aug 26, 2010 at 12:09 PM, Urs Lerch m...@ulerch.net wrote: Hi, I would like to call a vote for accepting ALOIS for incubation in the Apache Incubator. The full proposal is available below and on the proposal wiki page (http://wiki.apache.org/incubator/AloisProposal). We ask the Incubator PMC to sponsor it, with Scott Deboy volunteering as Champion and Mentor. Additional mentors are warmly welcome. Please cast your vote: [ ] +1, bring ALOIS into Incubator [ ] +0, I don't care either way, [ ] -1, do not bring ALOIS into Incubator, because... This vote will be open for 72 hours and only votes from the Incubator PMC are binding. Thanks, Urs = Preface = ALOIS is a log collection and correlation software with reporting and alarming functionalities. It has been implemented by the Swiss company IMSEC for a customer about five years ago. GPL-licenced, implemented in Ruby and completely based on other OSS-licensed components, it was designed for the open source community right from the start. Now that the software has shown its functioning over several years in production with the one customer and one IMSEC-internal installation, it seems to be the right time to open it to a wider community. = Abstract = ALOIS stands for „Advanced Logging and Intrusion Detection System“ and is meant to be a fully implemented open source SIEM (security information and event management) system. = Proposal = While almost all other SIEM software, be it closed or open source, concentrate on the technological part of security monitoring, ALOIS is aimed to monitor the security of the content. It intends to be pro-active in the detection of potential loss, theft, mistaken modification or unauthorized access. ALOIS works on log messages and thus contains all the basic functionality of a conventional SIEM, as centralized collecting, normalizing, aggregation, analyzing and correlating of all log messages, as well as reporting all security related events. Therefore it can be used as any other SIEM. ALOIS consists of five modules interacting to ensure a scaleable functionality of a SIEM: * Insink is the message sink, which is the receiving entry point for all the different log messages into ALOIS. It is partly based on the syslog-ng software. Insink listens for messages (UDP), waits for messages (TCP), receives message collections (files, emails) and pre-filters them to prevent from message flow overload. * Pumpy is the incoming FIFO buffer, implemented as a relational database tables. which contain the incoming original messages (in raw format). In a complex system setup, there may be several insink instances, e.g. for a group of hosts, for specific types of messages, or for high-avaliablity. * Prisma contains logic to split up the text of log messages into separate fields, based on regular expressions. Actually, prisma is a set of prismi, each one prisma for one type of log message (apache, cisco etc. Several prismi can be applied to the same message. This allows for stacked messages, i.e. forwarded log messages contained in compressed files contained in e-mail messages. The data retrieved form the log messages is stored in a database called Dobby. Due to prisma being written in Ruby, prismi can be applied interactively (when having system access). * Dobby is the central log database. It should be separated from the Pumpy database for availability and performance reasons. The current implementation is based on MySQL. * The Analyzer contains the two sub-systems Lizard and Reptor. Lizard is the analysis engine and user interface of ALOIS, implemented in Ruby on Rails using AJAX. It allows for interactive browsing through the collected data, exclusion/inclusion/selection of data, data sorting, data filtering, creation of views, ad-hoc textual and graphical reporting. Reptor allows for automatic activation of views and comparison of these views' results to a predefined result
Re: [VOTE] ALOIS to enter the incubator
OK, I read the syntax of this sideways. +1, binding, from me. On Thu, Aug 26, 2010 at 12:26 PM, Urs Lerch m...@ulerch.net wrote: Hi There is, at least in my opinion, a very clear statement regarding the licencing: = Source and Intellectual Property Submission Plan = ALOIS is currently under a GPL licence. Since there are only two contributors so far, both from the same company, there is no problem to re-licence the code and contribute it to Apache. The commitment of the company's owner has been granted. The names of the two contributors are listed elsewhere in the proposal. Do you think that ain't enough? Best Urs Am Donnerstag, den 26.08.2010, 12:17 -0400 schrieb Benson Margulies: I don't see anything explicit in here about relicensing from GPL to ASL. Perhaps that was hashed out before I joined the PMC? I'm +0 tending toward -1 without an explicit statement that the copyright owners are known and on board with the license change. On Thu, Aug 26, 2010 at 12:09 PM, Urs Lerch m...@ulerch.net wrote: Hi, I would like to call a vote for accepting ALOIS for incubation in the Apache Incubator. The full proposal is available below and on the proposal wiki page (http://wiki.apache.org/incubator/AloisProposal). We ask the Incubator PMC to sponsor it, with Scott Deboy volunteering as Champion and Mentor. Additional mentors are warmly welcome. Please cast your vote: [ ] +1, bring ALOIS into Incubator [ ] +0, I don't care either way, [ ] -1, do not bring ALOIS into Incubator, because... This vote will be open for 72 hours and only votes from the Incubator PMC are binding. Thanks, Urs = Preface = ALOIS is a log collection and correlation software with reporting and alarming functionalities. It has been implemented by the Swiss company IMSEC for a customer about five years ago. GPL-licenced, implemented in Ruby and completely based on other OSS-licensed components, it was designed for the open source community right from the start. Now that the software has shown its functioning over several years in production with the one customer and one IMSEC-internal installation, it seems to be the right time to open it to a wider community. = Abstract = ALOIS stands for „Advanced Logging and Intrusion Detection System“ and is meant to be a fully implemented open source SIEM (security information and event management) system. = Proposal = While almost all other SIEM software, be it closed or open source, concentrate on the technological part of security monitoring, ALOIS is aimed to monitor the security of the content. It intends to be pro-active in the detection of potential loss, theft, mistaken modification or unauthorized access. ALOIS works on log messages and thus contains all the basic functionality of a conventional SIEM, as centralized collecting, normalizing, aggregation, analyzing and correlating of all log messages, as well as reporting all security related events. Therefore it can be used as any other SIEM. ALOIS consists of five modules interacting to ensure a scaleable functionality of a SIEM: * Insink is the message sink, which is the receiving entry point for all the different log messages into ALOIS. It is partly based on the syslog-ng software. Insink listens for messages (UDP), waits for messages (TCP), receives message collections (files, emails) and pre-filters them to prevent from message flow overload. * Pumpy is the incoming FIFO buffer, implemented as a relational database tables. which contain the incoming original messages (in raw format). In a complex system setup, there may be several insink instances, e.g. for a group of hosts, for specific types of messages, or for high-avaliablity. * Prisma contains logic to split up the text of log messages into separate fields, based on regular expressions. Actually, prisma is a set of prismi, each one prisma for one type of log message (apache, cisco etc. Several prismi can be applied to the same message. This allows for stacked messages, i.e. forwarded log messages contained in compressed files contained in e-mail messages. The data retrieved form the log messages is stored in a database called Dobby. Due to prisma being written in Ruby, prismi can be applied interactively (when having system access). * Dobby is the central log database. It should be separated from the Pumpy database for availability and performance reasons. The current implementation is based on MySQL. * The Analyzer contains the two sub-systems Lizard and Reptor. Lizard is the analysis engine and user interface of ALOIS, implemented in Ruby on Rails using AJAX. It allows for interactive browsing through the collected data, exclusion/inclusion/selection of data, data sorting, data filtering, creation of views, ad-hoc textual and
Re: [PROPOSAL] Apache Isis
Thanks for that, Siegfried. I'm not actually putting this to a vote, yet, because we still need to find more mentors and a champion. If haven't yet done any cold calling of possible would-be mentors, but if you have any suggestions of anyone who might have the bandwidth for either role, I'd very much appreciate it! Thanks Dan ~~~ On 26/08/2010 17:12, Siegfried Goeschl wrote: Hi Dan, +1 (non-binding) Cheers, Siegfried Goeschl On 24.08.10 19:12, Dan Haywood wrote: I'd like to formally propose a new project for the incubator, Apache Isis. If accepted, Isis will combine the existing open source Naked Objects framework with a collection of sister projects, providing an extensible Java-based framework for rapidly developing domain-driven applications. I floated the idea of Isis on this mailing list about a month or so ago, and we got some positive feedback and a couple of expressions of interest in contributing. Since then, we've put together a proposal (also copied in below) onto the incubator wiki. The proposal is at: http://wiki.apache.org/incubator/IsisProposal. The current codebase is at: http://nakedobjects.org, with sister projects hosted at: http://starobjects.org We currently have two mentors, but require more, and we still need a champion. I'm hoping that this post will generate some further interest to develop the proposal further. All being well we hope to put this proposal to a vote in a week or two's time. Thanks for reading, looking forward to your feedback. Dan Haywood ~~~ = Isis Proposal = The following presents the proposal for creating a new project within the Apache Software Foundation called Isis. == Abstract == Isis will be an extensible standards-based framework to rapidly develop and enterprise level deploy domain-driven (DDD) applications. == Proposal == The Isis project will bring together a collection of open source projects that collectively support the rapid development of domain-driven applications. The heart of Isis is the Naked Objects Framework, an established open source project that has been around since 2002. In addition, it will incorporate a number of sister projects that build on Naked Objects' pluggable architecture and which extend the reach of Naked Objects in several key areas. In addition, the project will be reorganising the existing projects to logically separate out the components into [[http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/|JSR-299]] beans. We believe that the JSR-299 programming model is likely to become widely used for enterprise Java applications; adopting it should make it easier for new contributors to understand how the framework fits together and therefore to develop their own extensions. In turn, we hope this will further extend the reach of the framework to other complementary open source frameworks (either within Apache or outside of it). == Background == Naked Objects is an open source Java framework that was originally developed to explore the idea of enterprise systems that treat the user as a problem solver, not a process follower. Conceived by Richard Pawson, the first version of the framework was written by Robert Matthews (2002). Richard and Rob also wrote a book, Naked Objects (Wiley, 2002), to explain the idea. More generally, Naked Objects is an implementation of the naked objects architectural pattern. In its purest form, all the developer has to do is develop their domain model as pojos; Naked Objects then provides: a object-oriented user interface by rendering those pojos; persistence by extracting the content of the pojos; security by wrapping access to the pojos; remoting by turning local calls into remote ones; and localisation by adapting all the names used in the metamodel. All of this is done reflectively at runtime so that the developer can concentrate on the most important aspect - the application itself. You can think of Naked Objects' OOUI generation as analogous to Hibernate and other ORMs, but rather than reflecting the pojo into the persistence layer, they are reflected into the presentation layer. A number of other open source frameworks cite it as their inspiration, including [[http://jmatter.org|JMatter]], [[http://openxava.org|OpenXava]], and [[http://www.trailsframework.org|Trails]]. Over this time Naked Objects has attracted a fair degree of attention among the early adopter crowd, generally splitting opinion as either a very good idea or a very bad one. A common misconception is that naked objects is only appropriate for simple CRUD based applications. While developing CRUD applications is indeed trivial, an important innovation is that the UI generated by NO also renders the pojo's commands/behaviors (we call them actions). Simply stated: any public method that does not represent a property or collection is rendered so it can be invoked, eg with a button, a menu item or a hyperlink. We characterize
Re: [VOTE] ALOIS to enter the incubator
+1 notbinding On Thu, Aug 26, 2010 at 4:30 PM, Benson Margulies bimargul...@gmail.com wrote: OK, I read the syntax of this sideways. +1, binding, from me. On Thu, Aug 26, 2010 at 12:26 PM, Urs Lerch m...@ulerch.net wrote: Hi There is, at least in my opinion, a very clear statement regarding the licencing: = Source and Intellectual Property Submission Plan = ALOIS is currently under a GPL licence. Since there are only two contributors so far, both from the same company, there is no problem to re-licence the code and contribute it to Apache. The commitment of the company's owner has been granted. The names of the two contributors are listed elsewhere in the proposal. Do you think that ain't enough? Best Urs Am Donnerstag, den 26.08.2010, 12:17 -0400 schrieb Benson Margulies: I don't see anything explicit in here about relicensing from GPL to ASL. Perhaps that was hashed out before I joined the PMC? I'm +0 tending toward -1 without an explicit statement that the copyright owners are known and on board with the license change. On Thu, Aug 26, 2010 at 12:09 PM, Urs Lerch m...@ulerch.net wrote: Hi, I would like to call a vote for accepting ALOIS for incubation in the Apache Incubator. The full proposal is available below and on the proposal wiki page (http://wiki.apache.org/incubator/AloisProposal). We ask the Incubator PMC to sponsor it, with Scott Deboy volunteering as Champion and Mentor. Additional mentors are warmly welcome. Please cast your vote: [ ] +1, bring ALOIS into Incubator [ ] +0, I don't care either way, [ ] -1, do not bring ALOIS into Incubator, because... This vote will be open for 72 hours and only votes from the Incubator PMC are binding. Thanks, Urs = Preface = ALOIS is a log collection and correlation software with reporting and alarming functionalities. It has been implemented by the Swiss company IMSEC for a customer about five years ago. GPL-licenced, implemented in Ruby and completely based on other OSS-licensed components, it was designed for the open source community right from the start. Now that the software has shown its functioning over several years in production with the one customer and one IMSEC-internal installation, it seems to be the right time to open it to a wider community. = Abstract = ALOIS stands for „Advanced Logging and Intrusion Detection System“ and is meant to be a fully implemented open source SIEM (security information and event management) system. = Proposal = While almost all other SIEM software, be it closed or open source, concentrate on the technological part of security monitoring, ALOIS is aimed to monitor the security of the content. It intends to be pro-active in the detection of potential loss, theft, mistaken modification or unauthorized access. ALOIS works on log messages and thus contains all the basic functionality of a conventional SIEM, as centralized collecting, normalizing, aggregation, analyzing and correlating of all log messages, as well as reporting all security related events. Therefore it can be used as any other SIEM. ALOIS consists of five modules interacting to ensure a scaleable functionality of a SIEM: * Insink is the message sink, which is the receiving entry point for all the different log messages into ALOIS. It is partly based on the syslog-ng software. Insink listens for messages (UDP), waits for messages (TCP), receives message collections (files, emails) and pre-filters them to prevent from message flow overload. * Pumpy is the incoming FIFO buffer, implemented as a relational database tables. which contain the incoming original messages (in raw format). In a complex system setup, there may be several insink instances, e.g. for a group of hosts, for specific types of messages, or for high-avaliablity. * Prisma contains logic to split up the text of log messages into separate fields, based on regular expressions. Actually, prisma is a set of prismi, each one prisma for one type of log message (apache, cisco etc. Several prismi can be applied to the same message. This allows for stacked messages, i.e. forwarded log messages contained in compressed files contained in e-mail messages. The data retrieved form the log messages is stored in a database called Dobby. Due to prisma being written in Ruby, prismi can be applied interactively (when having system access). * Dobby is the central log database. It should be separated from the Pumpy database for availability and performance reasons. The current implementation is based on MySQL. * The Analyzer contains the two sub-systems Lizard and Reptor. Lizard is the analysis engine and user interface of ALOIS, implemented in Ruby on Rails using AJAX. It allows for interactive browsing through the collected data,
Re: [VOTE] ALOIS to enter the incubator
+1 On Thu, Aug 26, 2010 at 9:54 AM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: +1 notbinding On Thu, Aug 26, 2010 at 4:30 PM, Benson Margulies bimargul...@gmail.com wrote: OK, I read the syntax of this sideways. +1, binding, from me. On Thu, Aug 26, 2010 at 12:26 PM, Urs Lerch m...@ulerch.net wrote: Hi There is, at least in my opinion, a very clear statement regarding the licencing: = Source and Intellectual Property Submission Plan = ALOIS is currently under a GPL licence. Since there are only two contributors so far, both from the same company, there is no problem to re-licence the code and contribute it to Apache. The commitment of the company's owner has been granted. The names of the two contributors are listed elsewhere in the proposal. Do you think that ain't enough? Best Urs Am Donnerstag, den 26.08.2010, 12:17 -0400 schrieb Benson Margulies: I don't see anything explicit in here about relicensing from GPL to ASL. Perhaps that was hashed out before I joined the PMC? I'm +0 tending toward -1 without an explicit statement that the copyright owners are known and on board with the license change. On Thu, Aug 26, 2010 at 12:09 PM, Urs Lerch m...@ulerch.net wrote: Hi, I would like to call a vote for accepting ALOIS for incubation in the Apache Incubator. The full proposal is available below and on the proposal wiki page (http://wiki.apache.org/incubator/AloisProposal). We ask the Incubator PMC to sponsor it, with Scott Deboy volunteering as Champion and Mentor. Additional mentors are warmly welcome. Please cast your vote: [ ] +1, bring ALOIS into Incubator [ ] +0, I don't care either way, [ ] -1, do not bring ALOIS into Incubator, because... This vote will be open for 72 hours and only votes from the Incubator PMC are binding. Thanks, Urs = Preface = ALOIS is a log collection and correlation software with reporting and alarming functionalities. It has been implemented by the Swiss company IMSEC for a customer about five years ago. GPL-licenced, implemented in Ruby and completely based on other OSS-licensed components, it was designed for the open source community right from the start. Now that the software has shown its functioning over several years in production with the one customer and one IMSEC-internal installation, it seems to be the right time to open it to a wider community. = Abstract = ALOIS stands for „Advanced Logging and Intrusion Detection System“ and is meant to be a fully implemented open source SIEM (security information and event management) system. = Proposal = While almost all other SIEM software, be it closed or open source, concentrate on the technological part of security monitoring, ALOIS is aimed to monitor the security of the content. It intends to be pro-active in the detection of potential loss, theft, mistaken modification or unauthorized access. ALOIS works on log messages and thus contains all the basic functionality of a conventional SIEM, as centralized collecting, normalizing, aggregation, analyzing and correlating of all log messages, as well as reporting all security related events. Therefore it can be used as any other SIEM. ALOIS consists of five modules interacting to ensure a scaleable functionality of a SIEM: * Insink is the message sink, which is the receiving entry point for all the different log messages into ALOIS. It is partly based on the syslog-ng software. Insink listens for messages (UDP), waits for messages (TCP), receives message collections (files, emails) and pre-filters them to prevent from message flow overload. * Pumpy is the incoming FIFO buffer, implemented as a relational database tables. which contain the incoming original messages (in raw format). In a complex system setup, there may be several insink instances, e.g. for a group of hosts, for specific types of messages, or for high-avaliablity. * Prisma contains logic to split up the text of log messages into separate fields, based on regular expressions. Actually, prisma is a set of prismi, each one prisma for one type of log message (apache, cisco etc. Several prismi can be applied to the same message. This allows for stacked messages, i.e. forwarded log messages contained in compressed files contained in e-mail messages. The data retrieved form the log messages is stored in a database called Dobby. Due to prisma being written in Ruby, prismi can be applied interactively (when having system access). * Dobby is the central log database. It should be separated from the Pumpy database for availability and performance reasons. The current implementation is based on MySQL. * The Analyzer contains the
Re: Name change from Lucene Connectors Framework to Apache Connectors Framework
On Aug 26, 2010, at 12:09 PM, David Jencks wrote: On Aug 26, 2010, at 3:41 AM, Grant Ingersoll wrote: On Aug 25, 2010, at 10:26 AM, Upayavira wrote: On Wed, 2010-08-25 at 09:50 -0400, Grant Ingersoll wrote: So, how does this get resolved? Shall I call a formal vote for the IPMC? I rather like the name, but (somewhat) understand the objections. That being said, I'm not all that clever at naming, so... You rather like which name?? ACF My take: 1. come up with a name. 2. check for exixting uses of that name 3. if it passes #2 then get support of your PPMC 4. Propose it to IPMC. 5. Vote on the IPMC about the name. If you want, you can add #4a: discuss with IPMC whether a vote is really required for this, in which case you might be able to skip #5, but that process would probably be slower in the end! Well, I would argue we did all that, with the exception of a formal IPMC vote (although we did ask here). It seemed to pass muster until a week later, a fair amount of time after we went and made the changes. I responded within 5 hours of the proposal. AFAICT the PPMC members have not responded to that post at all. Agreed, you did indeed respond. We had the discussion on the Connectors mailing list. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
