Re: general questions

On Fri, 30 Nov 2001, Manuel Lemos wrote: > > It is unbelievable how everytime Manuel starts discussing with someone > > about Metabase the exchange of emails resembles a fucking flame-war. > > After reading what you wrote below, my conclusion is that either my > English is too bad or there is still a lot of misunderstanding maybe > because people may have missed some of messages or just read half or my > phrases, I don't know. What I know is that a lot of the discussions > could be avoided if people did not start assuming messages as personal > attacks or threats when the matters are only technical, at least that > always has been my intention. If you or anybody resent anything as a > personal, please read again. > Maybe so, let's see below. > > 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. > > - 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 ? 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. > > See above. Enough with all the "PEAR-DB lacks whatever feature" already. > > We know that, and until now noone complained or requested a feature to > > manage true data-types for instance. We already have the PEAR-DB done and > > being used here, so please stop with all this nonsense. > > I think you miss an important detail. A similar discussion was held in > php.dev about two years ago. Stig decided to not adopt Metabase because > it was "too complex". So he decided to roll his own thing. After all > this time what you see in PEAR-DB? Something still very far from > database abstraction that provides true portability and not schema > management facilities like Metabase and with a less than useful > documentation that any reasonable PEAR-DB user complains. > > My point is "why not adopting Metabase instead of waiting 2 or more > years for PEAR-DB to catch-up?" > > 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. > > One more time so you don't have any excuses to say the same thing all over > > again - we (well, Tomas and I at least) think that your proposal is a good > > idea, so let's work together on how to make this happen. > > I don't know what you think, but when I see somebody repeating himself > over and over again so that his message gets through and is well > understood, I am sure that that person is working really hard on trying > to work together. > I was also repeating myself a lot :) > > 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 ? > > Can you explain how would you have a _unique_ database abstraction layer > > for PHP if all the developers of the existing database abstraction layers > > do not agree on what step to take to build this _unique_ package ? > > I am convinced that you only not agree because you miss some points. > Stig did not seem to have such a understanding problem. > I hope so, because I would love to have an unique database abstraction layer for PHP. > > 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 can say for certain that I would not support something like that. > > Pushing ideas into someone else's throats is not the best idea for > > cultivating a supportive community, you know ;) > > It is your interpretation. I always proposed things to people. If you > don't agree, where your is alternative proposal? Just raising objections > is not helping. > > I just told you, I want to keep somehow the current PEAR-DB API intact. Be it by creating a wrapper and simulating the current API or not is fine by me. However, Lukas' opinion was that this was not going to happen if he did it himself. > > 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. Cheers, Joao -- João Prado Maia <jpm@phpbrasil.com> http://phpbrasil.com - php com um jeitinho brasileiro -- Precisando de consultoria em desenvolvimento para a Internet ? Impleo.net - http://impleo.net/?lang=br