Re: Adoption of Metabase (was Re: [PEAR-DEV]Re:Comparing ADODB with PEAR DB, Metabase andNative MySQL)

-- Apologize if this is are-post, little client problem. -- The way to get a voice in opensource is to start doing things, noone here really has any authority over what exactly is going to happen and thats the way PHP/PEAR/PECL works, if I get sick and tired of PEAR not having a decent installer yet then I either need to push stig and begin to ask what can I do to help etc or write one myself. The fact that Metabase's integration is being questioned is due to the fact it needs some work before it would fit into the famework and as far as I can see manuel is unwilling to do this. --------------- I agree but only to a certain extent. I've had plenty of people on the binarycloud list pipe up with some idea or concern that's 100% valid. I'm better off for it. Ok, if someone pesters for some feature but isn't willing to help implement it: they are annoying. --------------- reason why we cannot have Metabase and PEAR-DB and others if needed all in pear then the user can choose which api they prefer and which abstraction layer suits them better. --------------- Aghh! No! That's the whole point of pear: duplicative code that does the same thing is harmful in a repository like pear. Personally I think CPAN is a mess. So what? You can collect 10,000,000 files? Congratulations! Is any of it _useful_? I am a proponent of a merger of the best tools for the job: take the best from each and run with it ------------------ Manuel if you want Metabase in PEAR then get it to adhere to the standards to a decent level so that it is compatible with other PEAR elements, the idea behind pear is to create a framework that has a constant system of error reporting and dependencies. Metabase certainly doesnt adhere to this framework at the moment and that is where the main problem with it is. ------------------ Well, though I have not read his recent postings, I can guess that he probably thinks the work done on PEAR:DB is duplicative, and not to the same standard he achieved. I agree. That's why Metabase, not PEAR DB, is the abstraction layer for binarycloud. binarycloud uses PEAR code all over the place, in general it's good stuff. But I think PEAR has had a bit of an ivory tower problem, which has been greatly reduced if not eliminated, much to be releif. Everyone is interested in working with everyone else because we have the sense that this is all for our greater good. Doing work over again is not for the greater good. ------------------ If you came back and said look Metabase now works with PEAR and adheres to the standards set down by the PEAR development team (which are there for good reasons). Then Im sure there would be no problem incorporating it into PEAR, also if you feel its too much work to do all by yourself try and recruit a few other people to help you. ------------------ In this case I disagree. Manuel has put in a _HUGE_ amount of his time making this thing solid. While I agree that he shoud be involved in it, I think it is probably the respoonsibility of the community of developers who would like to use Metabase in its native-C or Pearized form to do the work to get it there. It's less work to convert metabase to pear standards than it is to get PEAR DB's featureset to match Metabase's. ------------------ FInally I hope you do port Metabase to PEAR as it will benifit both Metabase and PEAR, metabase due to the fact you will have more developers working on it and PEAR due to the fact that it will have a new database abstration layer which may suit some users better than the current PEAR-DB API. ------------------ I think the two should merge. _alex