RE: [PEAR-DEV] discussion about PEAR (was: MDB news)

Hi, since I was away over the weekend I will answer some of the thigns brought up over the weekend in this bulk mail. Since it seems to be that people are just pushing around the same old arguments because the other side is simply not listing I will refrain from quoting but just make some - for me final - comments on this thread. 1. MDB needs drivers for the major RDBMS before it can claim a to have a stable API (which so far I have never done anyways, but its important that people are aware of this) 2. So far I can't say that the community model has been a huge success for MDB (not much feedback), but also not a failure. There have been people helping answering questions from both sides of the merge. And there have been developers helping out with improving things, and even adding features and one driver. I hope that more people will step up and help out with the issue pointed out in 1 3. I didn't like the PEAR CS and it seems inconsistant in some places to me. However it was not that big of a deal to adapt. Just as I was able to work with the Metabase code I was able to work with the PEAR DB code. 4. There is definitely one project out there that shows great promise to ease the automatic changing of codeing style back and forth. So people will be able to maintain their coding style and just convert to PEAR CS with a push of a button. And they can convert PEAR CS based code to their style with a push if a button. Well to be honest there are limits: mainly in the API, since there reformatting can't do the trick. I don't know a good solution other than wrappers. In the case of MDB its not all that big of a deal since Metabase sort of always had a wrapper arund its base class. SO the MDB Metabase Wrapper is pretty fast (according the cheap benchmarks I have done: http://freshmeat.net/screenshots/30313/). 5. PEAR and phpclasses aim to achieve very different goal and therefore do not compete. PEAR aims to provide fairly integrated classes that also have a certain level of quality. Therefore it benefits greatly from a common CS. On the other hand phpclasses aims to be a repository of code. It does not require that the classes tightly interact nor that they abide by any CS. They also do not have to have the same level of quality as PEAR classes do. At the same time it is also false to assume that all PEAR classes are necessarily better than those found in phpclasses. 6. PEAR should aim to attract as many developers as possible, but not at the cost of loosing the benefits of a integrated class repository. Again this means a CS is important. It also means that PEAR should always listen to the arguments of developers that do not choose to contribute, because maybe these developers have good reasons that just weren't brought up when PEAR was concieved. Heck I did not participate in the initial creation of PEAR and the PEAR CS because I did not know what PEAR was about to be created back then. 7. We should all work much harder on ensuring that a certain level of respect remains while we discuss topics that are dear to us. We should not assume that people are idiots and if we are in doubt maybe a personal mail to the person in question would help to clear that up instead of voicing those doubts in the mailinglist, because it just creates hostility. Once a thread is infested with hostility it is very hard to continue any useful discussion. 8. Lets accept that sometimes each side has said all that there is to say and people still don't agree. Then its time to accept this and move on to other threads, development, real life etc. Thx, Lukas PS: I think the last X mails only went to pear-dev so that why I am only posting this to pear-dev.