Re: general questions

Hello, Joao Prado Maia wrote: > > On Fri, 30 Nov 2001, Manuel Lemos wrote: > > > "Tomas V.V.Cox" wrote: > > > > Also as Manuel pointed out Metabase is OO .. so porting is not that > > > > insanely difficult todo. Like I said we had some thing along the lines > > > > of the get*() PEAR DB functions in metabase in no time at all. > > > > > > > > Also Manuels code is not crap! And I do not see any point in redoing all > > > > of his work. If you want that then there is nobody stopping you from > > > > writing all of Manuels features into Pear DB and then there is no need > > > > for a "merge". > > > > > > Well, PEAR DB has all the features I need for my work. The rest of > > > > For now... I bet that in the beginning you did not need to have limited > > selects, but then you realized that you needed it and then you spent a > > lot of time working on something that Metabase already offered 2 years > > ago. What other Metabase features will you realize that you need in the > > future? Couldn't just you be denying that you may need the Metabase > > features just to not admit that this "merge" is not a good thing even > > for you? > > > > 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. > 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?". > - 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. > > I think if there is going to be any funny, it will be a consequence not > > a goal. I think it is more important to have vision that will let us > > work on something that is beneficial in the long term. Just for fun of > > doing it was what it seems that made PEAR developers start their own > > database abstraction package 2 years ago. After all this time, PEAR-DB > > does not offer database portability and many other features that > > Metabase offered already when PEAR-DB was started. It might have been > > fun for you, but that was not such a great progress because PEAR-DB > > still lags feature wise. > > > > 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. > 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. > > > > IMO the need for a "merge" has nothing to do with software, I see it > > > like the chance of joining developers to get more minds to build greater > > > > It's not just that. With only one database abstraction layer, you get to > > reuse each other components that have been developed independently but > > for the same API. You do not have to join people. > > > > 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. > 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. > Please explain how you would tell John Lim or even the PHPLIB guys to stop > working on their database layers and start supporting our effort. They I don't about PHPlib guys, I thought PHPlib development was dead. As for John Lim, I already extended the hand to him before but he did not want to accept to cooperate because of ego reasons as he admited. Maybe he would like to reconsider. It would only be beneficial for the success of his commercial database tool. > 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? > 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. > > > > So I must say my starting point will not be PEAR! I have no problem with > > > > the PEAR the function names that PEAR uses .. so I do not see a reason > > > > why not to use the same functions for the final version using those > > > > names (and therefore not requiring a wrapper to make use of those > > > > names). > > > > > > But Metabase is slow, why select it as the core? I have many ideas how > > > > Slow? Says who? Ah, John Lim who happens to be ADO-DB author and that > > sells a database tool that is based on ADO-DB. > > > > Anyway, is it just my impression or you seem to be using that just as an > > excuse for boycotting my database abstraction merger proposal? > > > > Yeah, that wasn't a good line I admit it. However, you already know that > Tomas supports your 'merge' proposal if it is kept open to everyone > (Metabase and PEAR::DB people) to agree on its terms. He is not > boyocotting anything for god's sake. Stop with the imflamatory remarks > where anything that doesn't go on your side is automatically a boyocot or > something. I am entitled to have my opinion of things as they look to me even if they are misunderstood. That is why I asked instead of affirming. > > > __IMHO__ if you want (I also want) to get succes don't came here in 4 > > > days saying: "Here I present you the new API of Metabase, take it and > > > use it". And I repeat, this is my only opinion. > > > > That is what Lukas is doing, but first he needs to learn about PEAR API > > to figure how one thing can fit in the other. > > > > 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. Regards, Manuel Lemos