Re: Potential proposal + request volunteers for champion & mentor roles - MetaModel
On 1/28/2013 11:07 AM, Kasper Sørensen wrote: Dear all, After some time spent (yeah, sorry quite a lot more time than we had hoped), we finally now have the green light to officially post a proposal to the Incubator to take on MetaModel as a project. Since it's been a while, I wish to call out again for sponsors. We found a few some months ago, but we where out of contact for so long I feel it's most fair to ask again. Please find below the draft proposal which we would love to further work on together with sponsors before finally submitting it. (I tried posting it on the wiki but was not authorized, probably because my account is a new one). Best regards, Kasper Sørensen - MetaModel - uniform data access across datastores Proposal for Apache Incubator Hello, I made few weeks a go a proposal (in very early stages of conception) that may marry very well with this project. You find the infos (very short at the moment) at the following URL: https://sourceforge.net/projects/rdbmssr It has to do with software redundancy on RDBMS so I'll be pleased if you may have an opinion on it and send me some further pointers about MetaModel. My idea was to target the most commercial databases first (Oracle, MS SQL Server, etc...) as the most widely used and to use as a language C/C++ for reasons of efficiency. Kind regards Federico - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] RDBMSSR: RDBMS Software Redundancy Proposal
Il 24/01/2013 11:54, Bertrand Delacretaz ha scritto: On Thu, Jan 24, 2013 at 11:50 AM, Greg Stein wrote: ...While I may disagree with the concept, I have no real opposition to people attempting to spin up projects here Me neither, I'm not opposing, just suggesting a way that might be more efficient. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org My first steps here are to discuss the general ideas and concepts. While I can work alone with Oracle and MS SQL Server, I've no experience with NOSQL RDBMS as Cassandra. That's why my attempt to "spin-up" the ideas on the Apache community. Cheers Federico - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] RDBMSSR: RDBMS Software Redundancy Proposal
Hello Greg, thanks for the reply. I just answer shortly to a couple of points you raised. IMO, RDBMS independence is a useless goal. Software deployments never wake up on a Thursday, and say, "let's change our database." Always, the goal is to store information, and to make the best use of the subsystem. This means you take advantage of RDBMS specifics. So this *really* means you're not changing the backend. The idea is in fact to have a *redundant *system against *RDBMS specifics failures*. This means that from *one unique* high level data model you derive "multiple paths" *specifically *designed for each different RDBMS. I have never seen a valid use case for a true, production system needing a switchable backend. *In fact, this idea for the proposal stems from the work I did in a large company, AMADEUS*. They do have troubles with down time of distributed systems caused by failures in the RDBMS layer. In fact, they do loose "millions" of euro's anytime they meet an uncovered bug in the RDBMS layer (Oracle, in this case). I think the same will apply to other large organizations. Similar API? Sure. But not exactly the same. The best apps will design for a specific backend, and will need specific API access. Yes, the idea would have to have *different handlers / managers specifically *designed for each *different *RDBMS system. The proposed concept of query abstraction across "paths" (whatever) goes even further away from proper app/db design. The idea would be to have *just one mathematically defined super-model* from which you may derive *specific models adapted to each different backend RDBMS*. Cheers, -g Thanks for your thoughts. Federico
[PROPOSAL] RDBMSSR: RDBMS Software Redundancy Proposal
Hello, I had no answer to the first post of this proposal, but I sent it during xmas holidays. So I send it again, I really would like to discuss the ideas proposed. Maybe you may suggest me the appropriate forum as well. Cheers Federico -- Short Description -- RDBMSSR: RDBMS Software Redundancy Proposal. PROBLEM / GOAL: avoid any loosing of up-time service of an application using either commercial or non-commercial databases due to yet uncovered and undiscovered bugs in database middleware. PROPOSED SOLUTION: Do make use of a redundant approach in the use of the database middleware by diversifying databases, schemas in the databases, relational or non relational data models, or using explicitly modifiers of any kind to SQL statements. The Multiple Paths model is proposed: do use multiple different paths and algorithms to access the very same data beneath them all. FILES: all the complementary files described below are available at the following URL: https://sourceforge.net/projects/rdbmssr . -- Short Description -- -- A bit Longer Description -- The basic idea is to generate from an unique input DataModel of the RDBMS hundreds of multiple paths per SQL statement. The way we generate the multiple paths is described in the powerpoint file "RDBMS_Software_Redundancy.pptx" (other format is "RDBMS_Software_Redundancy.html"). The basic idea is to use multiple databases (commercial as well as non commercial), to use multiple different schemas in order to model the same data (relational and non relational), to use the modifiers of any kind available for a given RDBMS platform in order to generate different SQL statements to access the same underlying data. Then we may attach a probability and a time-out to each path and do compute explicitly for all paths, summing up contributions. -- A bit Longer Description -- -- Proposed Solution -- The Proposed Solution will have (minimally) the following features: A) An abstract DataModel generator -> The input DataModel is entered and checked and from it, iteratively if needed, the whole number of different paths is generated. B) A software interface consisting of OR the DBO (Dynamic Business Object) model (presented as a very simple and short example in the "dbo.zip" file in C++) to represent data-types (intrinsic architecture) OR a pre-compiler able to adapt to existing concrete objects and able to generate adapted concrete classes (extrinsic architecture, no example given). C) A software interface consisting of the DB pool managers and handlers specific to commercial and non-commercial databases alike (as well as platforms). -- Proposed Solution -- -- PUBLIC DISCLAIMER -- The proposed idea is in its very early stage of conception, so any discussion, even if completely against it (but with good reasons), will be appreciated as well as any pointer to related on going efforts in any project. The author of this email claim to make the Proposal to the APACHE "brand" for an open discussion of such topic, ideas against and for, and any other help that may come from experienced open source developers. -- PUBLIC DISCLAIMER -- Thanks in advance Federico - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clean up users who are members of the "incubator" group and no other?
Hello, just speaking for myself, I recently joined the incubator group only to discuss a proposal. Let me know what do you consider about it. Federico Strati On 1/10/2013 10:17 AM, Bertrand Delacretaz wrote: Hi, Doing some cleanup/checks for the graduated Flex podling, I noticed a number of users at http://people.apache.org/committer-index.html who are just members of the incubator group, and no other group (starting from the top: acs, acymbalak, aditzel, etc.) Is there a valid use case for this? To me it seems more like people who were involved in podlings that were retired, or people who left podlings before graduation - so it doesn't make sense for them to be members of the incubator group. I'm tempted to remove those folks from the incubator group, to better reflect reality - WDYT? -Bertrand - 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
[PROPOSAL] RDBMSSR: RDBMS Software Redundancy Proposal
-- Short Description -- RDBMSSR: RDBMS Software Redundancy Proposal. PROBLEM / GOAL: avoid any loosing of up-time service of an application using either commercial or non-commercial databases due to yet uncovered and undiscovered bugs in database middleware. PROPOSED SOLUTION: Do make use of a redundant approach in the use of the database middleware by diversifying databases, schemas in the databases, relational or non relational data models, or using explicitly modifiers of any kind to SQL statements. The “Multiple Paths” model is proposed: do use multiple different paths and algorithms to access the very same data beneath them all. FILES: all the complementary files described below are available at the following URL: https://sourceforge.net/projects/rdbmssr . -- Short Description -- -- A bit Longer Description -- The basic idea is to generate from an unique input DataModel of the RDBMS hundreds of multiple paths per SQL statement. The way we generate the multiple paths is described in the powerpoint file "RDBMS_Software_Redundancy.pptx" (other format is "RDBMS_Software_Redundancy.html"). The basic idea is to use multiple databases (commercial as well as non commercial), to use multiple different schemas in order to model the same data (relational and non relational), to use the modifiers of any kind available for a given RDBMS platform in order to generate different SQL statements to access the same underlying data. Then we may attach a probability and a time-out to each path and do compute explicitly for all paths, summing up contributions. -- A bit Longer Description -- -- Proposed Solution -- The Proposed Solution will have (minimally) the following features: A) An abstract DataModel generator -> The input DataModel is entered and checked and from it, iteratively if needed, the whole number of different “paths” is generated. B) A software interface consisting of OR the DBO (Dynamic Business Object) model (presented as a very simple and short example in the "dbo.zip" file in C++) to represent data-types (intrinsic architecture) OR a pre-compiler able to adapt to existing concrete objects and able to generate adapted concrete classes (extrinsic architecture, no example given). C) A software interface consisting of the DB pool managers and handlers specific to commercial and non-commercial databases alike (as well as platforms). -- Proposed Solution -- -- PUBLIC DISCLAIMER -- The proposed idea is in its very early stage of conception, so any discussion, even if completely against it (but with good reasons), will be appreciated as well as any pointer to related on going efforts in any project. The author of this email claim to make the Proposal to the APACHE "brand" for an open discussion of such topic, ideas against and for, and any other help that may come from experienced open source developers. -- PUBLIC DISCLAIMER -- Thanks in advance Federico - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Info for submitting a proposal
say to put the documents and code on sourceforge, for instance ? Thanks Federico On 1/3/2013 4:57 PM, Bertrand Delacretaz wrote: On Thu, Jan 3, 2013 at 4:54 PM, Federico Strati wrote: ...Thanks, I'll prepare a short email then. (is it possible to attach examples in code, say a zip file?)... URLs to code repositories are much better IMO. -Bertrand - 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
Re: [PROPOSAL] Info for submitting a proposal
...I would like to know if I may explain in a short way my proposal here and be helped and redirected in case of overlap with existing projects... You're welcome to describe an incubation proposal here. Being concise often helps get people's attention. -Bertrand Thanks, I'll prepare a short email then. (is it possible to attach examples in code, say a zip file?) I may anticipate that it has to do with software redundancy applied to communication with databases. Any pointer would be useful. Best regards Federico - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[PROPOSAL] Info for submitting a proposal
Hello, I did review the guide for the proposal submission and I did review also the current projects, but, as I'm not an APACHE contributor, I may lack knowledge. Hence I would like to know if I may explain in a short way my proposal here and be helped and redirected in case of overlap with existing projects. Thanks in advance Kind regards Federico Strati - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
