Re: Re: one abstraction layer (my proposal for)

Hello, Lukas Smith wrote: > > Hi, > > Well I do have a little problem. > As several people have stated, this proposal will take a fair amount of > time to complete. I for one can't do with the "core" features alone. Exactly. Open Source projects do not happen if people do not have time to develop them. Therefore my proposal to just wrap PEAR-DB API around Metabase for now, instead of porting Metabase code to existing PEAR classes. Most of the people that talk will not do anything for this project because they do not fill capable or because they do not have the time to do it. Some people that is willing to do anything is just underestimating the time that it takes to do what Tomas proposed. Since the people that had interest to do it do not have time to make it happen soon, it is very likely that things will not happen and there is not much point to carry on this discussions. At least I tried to tell them that. If it was my English that it was not good enough, it was my fault, but I'm afraid there is too much people too biased against my person and Metabase that just force all sorts of inconsistent arguments to boycott my proposal. Anyway, I knew that this could happen, as you may recall I warned you 1 month ago when we met in Frankfurt way before these discussions that PEAR people is often ego driven and they are pretty capable to fight at all costs proposals like mine with tecnhnical and feasability merit, just to make sure they are the last ones to say the right thing, like children do. I am sorry that this did not go anywhere and I am afraid that in two years from now PEAR-DB is still be playing catch-up with Metabase when it could be different for the benefit of the whole PHP community, but at least I tried. Anyway, I am not going to spend anymore time in this discussion to not jeopardize my work which is certainly more important because that is from what I make a living and neither PEAR or Metabase are related to that. > We (as in my company) really need a db abstraction layer now (soon). > That was the reason we decided to make the move to Metabase. Even in > Metabase there have been little things missing that I need (you can read > up on that on the Metabase Mailinglist). > > So when I extend Metabase to what we need I thought I could also do some > improvements to the API. It was suggested that metabases features are to > be included into Pear DB. So I thought there is no reason not making > this new API a Pear compatible API. > > But I really do not have the time to go into Pear DB and write > everything that Metabase has and that Metabase is still missing a new. > Anyways I will do some benchmarking once I am done with the next major > software release of my company. There I want to see if switching to > get*() type functions in Metabase (which I have already written) the > lack of speed myth about Metabase can be done away with or not. It seems You don't need to do any benchmarks to send your improvements to Metabase. I know that your improvements are beneficial for users that want to fetch data in bulk with eventual speed improvements. So, just send your code over whenever you can. It will take sometime before it is ready to be released, because I need to document it and produce driver conformance tests to verify that the new features work seeminglessly with different databases. So, the sooner you send it, the sooner it will be released to others. > to be that this is the main reason why a couple people push for a > rewrite with a little cut and paste here and there (I do not mean "with > a little cut and paste here and there" as a negative thing!). > > Is this observation correct? The reason why people push for a rewrite of Metabase features in PEAR-DB is because they want to do it themselves. It is not a technical reason, it is a ego reason. It is the same reason why John Lim refused to cooperate, despite that merging would have been better for his commercial tool sales. The state of PEAR-DB is even worse. PEAR-DB development lacks of proper technical leadership. Stig could be leading PEAR-DB development properly but he is too busy, so you see a lot of things being done by others in ad-doc manner with no planning, development roadmap and you even see people kicking out estimates out for nowhere for development of piles of features in an unrealistic amount of time all based on wishful thinking and no software analisis. Then they complain when somebody points out that they lack of professional maturity and sense of commitment that is necessary for Open Source projects to be credible. > If it turns out that a rewrite with a little cut and paste here and > there is favoured way after all for most people then I will probably > only support this project a little more passively. This is not supposed > to be a threat (I am in no position to make any threats anyways - its > not like people stand in awe when they hear my name ... at least not in > this list ;) ) or anything like that. I just want to make clear how and Of course, you have already mentioned that you need to give priority to the business of your company that you depend on to make a living. So, it is only to you to decide how to spend better your time. > where I can help. I cannot wait 3 months to be somewhere that does not > yet match metabase features. If that happens I will rather do some > changes to Metabase in a couple weeks and port my application to > Metabase. Right. If it would happen in 3 months it would be so bad, but they are not even planning the schedule for the development of each thing that was proposed, so just don't count on that. Let's just stick to what already exists and is reliable. Regards, Manuel Lemos