Re: general questions

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. 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 - 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. > 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. 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. > > 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. 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 ? 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 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 ? 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 ;) > > things. Noone is willing to rewrite anything. I previously said it, the > > way IMHO this could get some success is writing a spec that "all" the > > people agrees and then cut & paste the best pieces of code from each > > abstraction layer. > > Keeping different database abstraction packages is what we already have, > so what you suggest does not represent any progress. > Again, pushing whatever you or Lukas think it is best for a database API is not the way to go here. You _will_ lose support if that happens, and thats what Tomas was saying in there. Again, you _will_ lose support if the developments of this new 'merged' API are done isolately. > > > 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. Read this slowly now: _we are discussing how the new API would be developed, chill out_. If you still have the need to reply an inflamatory remaker, read the above phrase again. And then again. > You should know by now that Metabase offers many outstanding features > that others don't (if not, you had plenty of time to go and learn about > it), so why this objection? > Again, stop with the 'Metabase has more features' already. You won, it has more features. So let's discuss how to work together. > > __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. Why don't we stop with all the nasty remarks and start working _together_ on the new API ? After all, if we don't work _together_, how is this a 'merge' anyway ? If we don't work together it would feel much more like an assimilation than anything else :) 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