Re: general questions

On Fri, 30 Nov 2001, Manuel Lemos wrote: > > 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. > There is no progress Manuel, please understand this. If he is the one doing the wrapper why is this thread keeping him from working ? He can work on whatever he wants, and like I told him we will give him the suggestions for changes. > > 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. > Did it ? I don't see anyone telling me that they understood and that things are going in the way that they should be going. I only see Tomas talking about the issues of the new API, and everyone basically just following the thread. > 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! :-) > English is english. When someone tells that he will oppose modifications, then thats what it means. Anyway, this case was explained and everyone is happy. Let's move on. > > 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. > Whatever Manuel. I still think you are wrong here, the developers need to be together to make this work, not just an utopic dream of a "unique API" for the poor PHP users. If the developers are not together, then the 'unique API' will just be another API. > 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. > What difficulties, for god's sake ? We just accepted your proposal to create the wrapper and we are discussing ways to build this new API and this is somehow 'raising difficulties' ? And about 'proposing alternatives', we can only do that once we understand the way this new API will be created. In any case, whatever, Lukas Smith will do the new wrapper and we will propose alternatives then. Exactly, once everything is finished we will propose the alternatives, not before! *hah* > > > > 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? > Huh ? So you asked if I was willing to collaborate on the development and now that I said that I was you told to 'sit' where I am ? You need some serious attitude work, my friend. Do you understand now why so many people give up on working together with you ? Because of this fucking attitude of 'this is the way to go, if you don't agree go sit in the corner'. I'm not even sure why I care so much, I _really_ should just be quiet like everyone else and watch this proposal fade away without the lack of support. 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