Re: general questions

Hello, Jason Lotito wrote: > > There is no progress because you keep raising the same > > objections based on your misunderstandings of what people > > keep trying to tell you that it is not as you think, but you > > insist on misunderstanding making people spend a lot of time > > replying to you persistent objections instead of working on > > making progress in what was proposed. > > There is no progress because _you_ keep raising the same objections to > people's questions and concerns based on your opinions of what people > _should_ be thinking and _should_ be doing. You made a proposal. If you read the whole thread carefully, can you tell exactly what questions and concerns where not answered by me or Lukas? Maybe it is our English because none of us is a native English speaker. > Rather than constantly repeat the same thing over and over again ( > MetaBase has more features, and not adopting it (in some manner, etc) is I never meant to say that Metabase has just more features in number. I meant to say that Metabase provides valuable features that other abstraction layers do not provide, nor have any perspective if and when those features will ever be added. Then somebody claimed that he would not need such features. I explained that today you may think that you don't need them but you never know if you may not need them in the future. Lukas also explained, maybe in a not so obvious way that, there is intention to make feature sets loadabled only if the developer needs them. He also mentioned that he disagreed that feature sets that are redundant should be loaded as default, like the get* vs. fetch* like functions. There was a great misunderstanding and so Lukas tried to explain once again. Anyway, if it was not clear before, I think I have made clear that my point is not Metabase has an higher feature count, but rather that Metabase has very valuable features that are very hard and take a very long time to implement and also that for those that do not need such features, they will be loaded optionally. > dumb ) discuss the issues your peers have come up with. And I hate to > say it, but that was your whole point. That is what you kept repeating, > kept announcing over and over again, and what you made it seem like. I think you just been reading my message and not paying attention to Lukas messages. Maybe it is time for you to go through them so you can understand why I am saying that I have been repeating myself more than any sane person and patience and free time to do it. > Some of use, myself included, made an educated decision on why NOT to > use Metabase and chose ADODB or PEAR or PHPLib over it. Just because > Metabase works for you doesn't mean it works for everyone. I will > refrain from making any comparisons with Mircosoft here. I know you are > smart enough to understand this and know it to be true. I think you miss the point of the whole vision, but I will try to explain it again. If all goes well, in the end you only have PEAR-DB. My proposal is to wrap Metabase around PEAR-DB API. PEAR-DB API will be enhanced to provide an interface for Metabase features that PEAR-DB does not offer yet. If all goes well, Metabase API functions can be ported to C taking whatever it takes to do it, but until that is done you can already benefit of Metabase features with a PEAR-DB API today. In the end you will not see Metabase anywhere except for the features that PEAR-DB inherited from it. If it makes anybody happier I will not want my name mentioned anywhere. My goal is honestly to have only one database abstraction layer for PHP, and certainly not to get in the hall of fame of PHP or PEAR. The benefit of having only one database abstraction layer that provides the features that Metabase offers and more are satisfactory enough for me regardless of any personal credit that I abdicate. > > I don't know what you do for a living, but most of us work, > > so there is no time nor patience left to replying to your > > annoying messages repeating the same misunderstandings. I > > don't see any good will on your part in trying to understand > > that we only want to have the best for PHP which in this case > > is having only one database abstraction layer based on > > something that exists today with highly desirable features. > > For who? What desirable features do you talk about? Stop being so Read above. > general in statements like this. I know many developers who would love > Metabase, and many who wouldn't. Reasons NOT for Metabase? Currently > is has not manner on which to handle stored procedures as one example. Have you ever requested that to me or anyone envolved in Metabase development? Honestly I don't recall. A lot of people have been making feature requests for Metabase. I never stoped responding to those requests. > Another is that using a light front API layer like PEAR's is faster (No, > I don't have benchmarks to prove it, its simple fact and you are a smart > enough man to know it, the more abstraction, the slower the system. > Period.) in response time. Sure, moving a complete database over isn't The official Metabase API is in such way that it works properly under PHP 3. PHP 3 is what existed when Metabase was developed initially. I can't remove the current Metabase API because it would be extremely irresponsable and unprofessional to drop the support to all the applications that rely in that API. That does not mean that Metabase could not have more than one API. Actually my proposal was to wrap Metabase around PEAR-DB API. Actually, it could skip the actual Metabase* functions and go directly to the driver classes. Since the beginning of Metabase you can do: $db=new metabase_mysql; $db->Setup(); etc... This is what the Metabase factory function MetabaseSetupDatabase() does. From then on you may call the driver functions directly, but there are some problems of PHP regarding object copying that the Metabase* functions avoid. These problems will only be cured with PHP 5 whenever it comes out, according to Zeev Suraski. Anyway, with proper care, Metabase driver class functions can be called directly from a PEAR-DB wrapper interface that I proposed. Lukas already mentioned his interest to have an interface more like this for Metabase. That is why I addressed directly to him to suggest that he does it. I don't see the point of asking that to more than one person. Also, when I made my initial proposal I was accused of ordering somebody to port Metabase to C. So, I am no longer suggesting that anybody does anything unless I know that he was already willing to do it. But then I was accused of only asking Lukas to do it and nobody else. ....... You have to admit that this drives anybody sane out of patience. "I would be busted if I said I have dog, but I also busted if I say I don't have a dog." From situations like this comes that saying "A camel is a horse designed by a comittee". If I knew what I know now, I would have talked with Lukas to do a PEAR-DB interface prototype for Metabase before I presented my proposal. At least I knew that the prototype would be already be a horse, and not a camel. > going to work with something like PEAR, but neither will it now with > your meta system. SQL queries to the database will still have to be > rewritten for optimization, new triggers will have to be written up, Sure, but people that want to invest in optimize for a given database, ought to interface to its native API for maximum performance. I already mentioned this several times. What part of it didn't I or you understand or agree? > etc. The idea of simulating auto_increment in MySQL seems less than > optimized (going by what I have read in your manual/tutorial), and is > something that really turned me off. That was NOT a feature I wanted, > hack attempts to make everything work (which is what it seems like in > some cases from a user point of view). It is funny that you say that because PEAR-DB people have copied that feature almost verbatim. To be consistent, is PEAR-DB is also a turn-off for you because of that? > You seem too ego driven in your drive to install Metabase as the PEAR DB > system. This is not an insult, merely an observation. A point this out Yes, I take that as an insult not because your perception of me being ego driven on this initiative, but because you said you read all the messages and still miss points that I repeated more than once. For once get this straight, my proposal to adopt Metabase now is so PEAR-DB can be a truely portable database abstraction layer and have other features now, not in two years or whatever it takes for PEAR developers to first believe they are good features and then to develop them. I already said I proposed Metabase not because I did it, but because what it offers. If you keep insisting that I am being ego driven, either you don't understand my non-native English speech or you are saying that I am lying. This certainly hurts me badly, because my proposal was all for the best of PHP and nothing at all for my person. Anyway, my impression is that you do not think of me as a trustworthy person to come up with my proposal for non-ego related motives. If you don't trust me, I am sorry, I do not have anything else to say to you. Manuel Lemos