Re: general questions

Manuel Lemos wrote: > > Hello, > > "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. Well, Metabase doesn't offer the stuff I'm trying to do for the Oracle limit support. For the others drivers one haven't to work too much to get it running. > 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? My god, when I ever said that? I was only talking about my personal experience with PEAR. > > things are not of my personal interest and my only interest on them is > > So, because it is not of your interest, it could not be of the interest > of anybody else? Is that what you are saying? Bah Manuel, don't try put my words out of context. The 80% of the things I have contributed to PEAR are not of my _personal_ interest. I spent 2 days with the Oracle limit support, install a Oracle at home, break my head in that and try to make it work, for what if I'm not using Oracle nowadays? The same applies for a bounch of other things like the DB_FETCHMODE_OBJECT (I don't use it as it's more confortable for me the ASSOC) or the tutorial (I do know already how to use PEAR DB) for putting some quick examples. > > only because this is a Open Source proyect and I get fun developing for > > it (or it isn't the reason why we are here?). > > Fun? Have you been reading too many Linus books lately? :-) No, but for sure I would have to :) > 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. Just for fun or not PEAR DB had have quite success. Just for fun or not many Open Source proyects are beating propietary software in many areas. And for your eternal statement about the "features", yes we all agree. But if there is no other abstraction layer that do some of the unique things of Metabase is because all others failed to implement them or perhaps they consider that aren't really so necesary? > > 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. First we join, then we develop, isn't the objective of a "union" to build one database abstraction layer? > > 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. > > > > 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). > > > Anyway, is it just my impression or you seem to be using that just as an > excuse for boycotting my database abstraction merger proposal? Nop. I'm all open of a team merge and to build the ultimate abstraction layer. But if you are trying to do that by your self, with your own rules, your software, etc. probably I won't contribute to it. But that's only me, you don't have to worry about me. I'm only buzzing here trying to ensure that this is really open to others. By the way, please tell me what exactly you mean with "my database abstraction merger proposal", the "Adoption of Metabase"? > 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? > > > to simplify the PEAR architecture to make it more lightweight/fast > > without loosing its great usability. And that's me, others will have > > better ideas. > > > > What you are wanting to do is to rename Metabase functions to be more > > similar to PEAR DB? It's the same statement you said before: Stig's code > > is not crap! Why not just do a better API for Metabase and forget the > > merge? ;) > > Duh? That's what I proposed, wrap Metabase API around a PEAR-DB driver. > > > __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. Umm ... perhaps my limited english is confusing me, but I though that Lukas agreeded with me about starting this stuff from a more common point instead of directly use the stuff you think is better (what was about the bad that the "ego" is?). > > > I will not port some of the stuff that is part of the PEAR DB fetch*() > > > stuff. Those features basically allow a programmer to write bad SQL > > > queries and then do the real sorting/searching inside of PHP. But anyone > > > else is obviously welcome to do this. > > > > Huh? I you don't port fetch* you won't be able to retrieve rows :) You > > are refering to other thing no? > > Not, Metabase does not need cursor positioning functions, because it > lets you specify row numbers in the data fetching calls. If those will > be implemented is just to emulate the sequential interface of PEAR-DB. PEAR DB supports fetching rows by number, I implemented that for the Pager long time ago. We can end old discussing and discussing, and all can be just resolved if you clearly write somewhere your idea/goals, who is involved on it and how you plan to implement it. With that no more discussion posible, if people likes the idea will help and the ones who think other thing will continue their lifes. Tomas V.V.Cox