Re: general questions

Hello, Joao Prado Maia wrote: > > > Manuel, please understand what Tomas and I were talking about before: > > > > > > - We agree that Metabase has more features and that its advanced features > > > like XML schema management and true portability are really interesting and > > > important > > > > It was not that clear that Tomas thought that. He was still asking "why > > Metabase?". > > > > Read the paragraph just below here > VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV > > Why Metabase ? Because we think the PEAR::DB design is more clean and > structured. Read the whole paragraph below. Isn't that just a biased thought? The greatest difference between Metabase and PEAR-DB is the API. An API is just the skin to a body. Metabase can have different skins for the same body. What I am proposing is to make Metabase have also an enhanced PEAR-DB skin without the need to change the body because that would take too much time. Since I have repeated this an enormous amount of times, I get the impressions that who is still asking "Why Metabase?" is just stalling to avoid the proposal to go ahead. If that is not the case, stop asking "Why Metabase"! > > > - We also agree that we think that PEAR::DB's design is more clean and > > > well-structured than Metabase's one. Think about class relationships and > > > etc here, not about its features. This is why we say that we rather add > > > the advanced Metabase features to PEAR::DB instead of the opposite. > > > > Then you need read my proposal again because what I proposed is (and I > > am reapeating myself) to provide Metabase features right away (not in > > more 2 years or whatever it takes) by developing a PEAR-DB wrapper > > (driver class or whatever) that would interface to Metabase. > > > > Implementing Metabase features into PEAR-DB is not a realistic proposal > > because it would take an eternity. > > > > So you are saying that a PEAR-DB wrapper will be created on top of > Metabase, so we have all the features quickly. Well, the problem here is > that Lukas Smith doesn't seem too fond of the current PEAR-DB API, as he > described ever so interestingly about his opinions of the fetch*() > methods. If he doesn't do a full port, how is this a real wrapper of the > PEAR-DB API if a lot of its methods are missing ? You got him wrong. He explained that to you. I hope you stop raising objections because you are only stalling the progress. > Or are you saying that the port will not take the current PEAR-DB in its > entirety ? 'wrapper' and 'interface' are all very cool words but we need > hard facts here. Read slowly: we are discussing the proposal to see how to > create something that can work for both fronts. I get that most people got it right from my initial proposal, so please get over this. > > I don't know about you, but a lot of PHP users value their time so much > > that they can't wait that long for the hope of PEAR-DB to ever catch up. > > So, this is the big opportunity. Either you take it, or let PEAR-DB > > users keep complaining about it misses and Metabase could provide right > > away. > > > > You didn't actually read my paragraph, did you ? :) > > Yeah, why not adopting Metabase ? I'm agreeing with you that we should > create this wrapper now, but I still want to talk about the way that we > are going to do this. > > If Lukas Smith will really create this new wrapper and later 'violently > oppose' contributions like the fetch*() family of methods, then we have a > problem. I hope it is all clear for you now and Lukas does not need to to draw pictures since it seems his English was not clear for you! :-) > > > Yes, you _do_ need to join people. Read this carefully because the way > > > this thread is evolving, no 'merge' is going to happen. > > > > You still miss my point. I am not talking about us, but about others > > that will develop applications and components based on one database > > abstraction layer that will never participate in the development of this > > layer. > > > > And I'm talking about the developers of this layer. After all, if you do > not have the developers together, they will end up creating yet another > abstraction layer and then we will have N+1 layers instead of N. Do you > understand my reasoning here ? You changed the scope of my phrase. I am not going to explain it to you again. > > > will _not_ join any 'merge' where they do not have any say about the > > > project. Thats simple logic - the PEAR-DB guys only worked together > > > because they could agree on the same issues while designing the package / > > > or even designing the changes to the package. > > > > > > This is why I'm writing this email - how can the PEAR-DB people support > > > your supposed 'merge' if only Lukas Smith will work on the new API ? Will > > > it be Lukas' API or will it be the new _unified_ API ? > > > > Here I think you only read half of what I said. Lukas was already > > willing to develop a "more OOP like" API for Metabase (it takes a lot of > > patience and commitment to keep repeating myself several times a day). > > What I proposed is that he would write a API that could fit in PEAR-DB. > > Then I said he would present the results. Of course if the results are > > unsatisfactory, things need to be changed to be accepted. What else do > > you want? Keep discussing things forever so nobody gets to do anything > > any time soon? > > > > Hey, it's not about discussing things forever. The proposal was made to > the pear-dev list and we are talking about it now. If we can't discuss the > way this is going to happen, then it wouldn't be a proposal, but rather a > affirmation (i.e. 'things are going to happen like this and that is it.') I'm sorry, but I can't help feeling that you are acting like bureaucrats that keep raising difficulties to stall the proposal. All I hear from you is, "I agree with that but that....". If you don't agree with something, propose alternatives. Just disagreeing is not helping, it is just stalling the things. > > > It's good that he is learning PEAR::DB's API to help on this work. > > > However, he definetely should not be the _only_ developer doing this. > > > > What does that mean? Are you willing to code what I proposed to Lukas or > > you are just providing your opinions? If you just want to provide > > opinions, what is your problem that Lukas does it without having to wait > > for whatever everybody thinks? I think it is much more productive if one > > person does it and the others evaluate later and propose changes if > > necessary. > > > > Yes, I'm willing to code if noone else will get the responsability to try > to keep the current PEAR-DB API intact (I have production code using > PEAR-DB in here, you know ;). I also agree that it would be more > productive if he did the initial version and we would propose changes > later. _However_, he seemed very unwillingly to accept modifications that > would keep the fetch*() methods for instance. I just wonder what other > features he would remove. Why don't you just sit there where you are and see what Lukas will work out and make your criticisms then? Regards, Manuel Lemos