Re: Re: [metabase-dev] MDB news

On Thu, 2002-09-05 at 21:36, Manuel Lemos wrote: > Hello, > > On 09/04/2002 01:04 PM, Paul Cooper wrote: > >>I think you should first port all drivers before you add new features to > >> parts of the package that depend on features of the abstaction layer > >>that need to be added or improved. > > > > > > This would be nice in a perfect world, but given the current make up MDB > > hackers this would mean that you could expect a release sometime in > > 2005. Lukas and Christian seem to use mysql and I use mainly pgsql, > > mysql a little, and interbase even less. > > That is ridiculous. I started Metabase in late 1998. I released it early > 2000. It took a little over 1 year before I decided it was ready for > release with 6 drivers. Most drivers were ready very early. > > The reason why I waited a year was so I could give myself sometime to > learn and reflect about the diferences between each database so I could > be certain that once I released it to the public I would not be able to > change the API in a backwards incompatible way. I am glad I did it as > life taught me that important ideas need some time to mature. But our code is currently available via CVS - a release is just a fixed (hopefully working) point in the flow of cvs, which at any random point in time could have broken code in it. Metabase development seems to use a different method of development (at least I couldn't find a cvs for it), it seems you develop in private and release alphas, betas, and releases. That's cool, I'm not trying to argue that one method is better than the other all I'm trying to do is point out that they are different. Our code is 'released' every day and available for the 'public' to use if they are fool hardy enough to use anything directly out of CVS. > Since you hardly need to add any database related features to the > drivers, your claim that it would take several people a long time to > port all the drivers is absurd. That's not what I meant - what I mean is that is may take these 3 hackers a long time since we may or may not be interested or have time to port the metabase drivers other than those databases we use. > As a matter of fact, I always told you to leave the cosmetic fixes that > PEAR people insist that is necessary to a later phase. That was used as > an excuse by Metabase detractors to stall the merge. > > Since people are now willing to accept Smarty without requiring any > pearification, there is even no longer that argument of stalling > Metabase x PEAR merger because after all I proved to be right from the > beginning that the pearification process would be needlessly lengthy and > error prone because whoever does it is always at risk of introducing > bugs where none existed. > > I come here and bother to share my real world experience but still I > have to put up with unexperienced people claiming that the cosmetic > fixes, which is mostly what pearification means, are necessary, when all > we see is that those that claim pearification as necessary will not do a > damn thing to help. > > Basically, I proved to be right when I claimed they were just stalling. > What I got was just silly accusations that I was being paranoid. So > there you have it. At this pace the Metabase x PEAR-DB merger will not > happen anytime soon. I'm not sure I understand what you mean with all this - are you saying that MDB is not necessary and we should just import Metabase into PEAR as is and then only gradually 'pearify' it? > Porting just to MySQL or PostgreSQL will not assure that the portability > assumptions were right, despite Metabase original drivers were proved to > be as portable as they could be. The problem is that Lukas keep making > changes before other drivers are ported and such changes eventually > break portability. > > The question is, when will people ever trust my experience and start > listening? Maybe when they reach maturity and stop the childish > anti-Manuel-Lemos work atitude. I don't have any anti-Manuel attitude - it was your persuasive arguments that changed my opinion on some kind of PEAR Metabase merger. The problem we end up with is this; while probably the majority of the code in MDB line by line code is yours, stolen out of Metabase, your comments are easy to perceive as those of an outsider, since you have not been involved in the commit to commit developement of MDB (whereas you are probably more 'inside' MDB than any of us). It's also difficult to know what to do with your comments when then basically you seem to be saying that what we are doing is all wrong, that we don't respect you or trust your experience. If I didn't have any respect for you I wouldn't steal your code or bother replying to your mails. > > An interbase driver is on my todo list, but only after I've ported (and > > added to) the metabase testing script to PHPUnit (because the metabase > > script has to go through the metabase_wrapper it involves too many > > layers, we need testing that directly manipulates the MDB api, but it is > > a starting point to copy). > > That is yet another silly needless thing. Metabase driver test > conformance script proves that Metabase is portable as it should be. It > doesn't matter what is underlying it, being that the original Metabase > drivers or the ported to MDB. So, porting the tests to PHPUnit is yet > another waste of time. The metabase driver test is great for testing metabase - however in MDB metabase api is provided by a wrapper, so in the event it shows up a bug there is an extra layer to investigate. What I want is the same tests directly accessing the MDB api - but (if I have understood) your thesis is that MDB is wrong and Metabase should be imported as is, then you are right I am wasting my time. > I don't care go ahead, your 2005 projection is probably right. You are > learning at your expense. By the end of it, you realize that you hardly > added enough to justify the time you spend redoing things. > > > > Those of us who actually use MDB need a release x.0 target which we can > > then branch into a devel x.1 version. You can argue about what the value > > of x should be (e.g. 0.5, 0.7, 1) but I think we something 'firm' and > > bug tested so that; > > If you did not bother to make so many cosmetic changes, the chances of > still having bugs would have been gone. It is not that I haven't warned > about that before. > > > > a) We can use in client projects with out having to worry about CVS > > bleed, > > > > b) we have a fixed target for bug reports and fixes. > > > > c) Early adopters can test and play and hopefully get exited enough to > > write the driver they need. > > That is wishful thinking. It may happen, but chances are that it won't. > > > >>That has always been a problem with PEAR-DB API. Early versions were > >>released to the public with features that were not tested in all > >>databases so they had to be redone, patched or have ugly optional > >>arguments to assure compatibility with something that was badly designed. > > > > > > I think we should combat this by just being ruthless about backwards > > compatability until the API is stable and we have a good range of > > drivers (i.e. change the api as needed until we have all the drivers). I > > That is the unprofessional way of doing it. The reason is simple. While > you do it, some people will try it and get burned because you keep > changing things and they will not bother to try it later because once > burned, twice shy. > > > > think you have a point if you argue that we should not be having a 1.0 > > release - maybe a 1.0 should be reserved for MDB with stable API and > > most drivers, and we should be releasing 0.5 or something. But in the > > end the numbering is just arbitrary so we just have to agree a roadmap. > > Version numbers are irrelevant because they are misleading. I never use > 0.x 1.x or whatever. I use YYYY.MM.DD . That way people will know how > old things really are and don't make assumptions about stability. > > Anyway, that is just me. I am not that way by accident or because I am > just being stubborn to not admit anything somebody told otherwise. I am > that way because my life experience told me that is more convenient. You > may either learn from the experience that I am sharing or just remain > stubborn against what I say and soon or later deal with the consequences > of not listening from those that share their experience. Yes, but do you want us to listen and meekly and blindly do whatever you tell us ;-) Realistically! I've got experience too and a viewpoint and you can't simply trump them because you have more. Paul > -- > > Regards, > Manuel Lemos > > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php