Re: general questions

Joao Prado Maia wrote: > > On Thu, 29 Nov 2001, Lukas Smith wrote: > > > > > Well obviously nobody wants functionality to break. Neither metabase nor > > Pear DB. But if we want this thing to be good I do not want to slow > > things down to much by legacy support. So what I will try to do is > > provide wrappers for both Metabase and Pear DB. > > > > What type of "wrappers" are we talking here ? Are they going to be just > another class on top of the existing Metabase and PEAR::DB APIs ? Or are > we talking about re-writing the whole PEAR::DB to enable the features > available on Metabase ? In my opinion, the resultant class don't have to be a wrapper over anything, it should be the final "native" abstraction layer. The wrappers, if people want them, would be done over this class for every team that have and abstraction layer done and want to help their users the migration. > I find the idea of Classes on top of Classes, which are on top of other > classes and so on kind of scary. PEAR::DB is rated 'slow' on some > benchmarks like it is today because of all the setup time it needs to do > to create the class definitions of all the needed stuff. Isn't this going > to slow things down even more ? > > I understand that the original proposal of Manuel Lemos was to provide > PEAR::DB with the features of Metabase as soon as possible, but creating > something that is flawed by nature cannot be a good goal. We should think > about the speed issues before starting to work on anything here. > > > Form a design perspective I will want to do it right though. Only if we > > later find that this doing it right prevents the wrapper to work right I > > would consider changes from this "glorious path." > > > > So step one would be to define the new API (this will be very similar to > > Pear DB in many respects) and bringing all those neat metabase features > > under this umbrella. Then in the next step wrappers are created for both > > metabase and Pear. > > > > Strange, from what you are saying here you sound like you want to re-write > the whole thing. Manuel said it clear: "I think there is some misunderstanding. The point is not to drop PEAR-DB API but to evolve it to support Metabase features so PEAR-DB users can benefit from them" To this I would add:" and benefit Metabase from a gain of usability, speed, users, contributions and if that get success be part of the PHP distribution". > > So is everybody cool if I give this thing a shot? Or is anybody else > > interested in doing this themselves? Are there people I should be > > talking to directly? Anyone that has an awesome idea that this heavenly > > new Db abstraction layer should have? Ideas how things could be better > > etc. > > > > Well, I would suggest you to develop this thing on PEAR's CVS repository > under /pear/Experimental or something like that. The people who is wanting to join to this proyect should apply for a CVS account and create a new directory under the "pear" module of the PHP's CVS. The name of that? Well, Stig proposed MDB, I would prefer something more open like PDB (from PHP DB) (please don't propose names more longer than 3 chars). > I bet that there are lots > of people interested in working on this, especially Tomas Cox or Chuck. > > In any case, I might be able to help if we keep the objectives clear. In > my personal opinion, I rather have the current PEAR::DB intact when > possible and add the Metabase features. > I'm in the same position of you Joao. I'm not sure what are the objectives/goals/plans of this idea. If you want to add to Pear the missing features of Metabase, yeah I want to take part on this. Only say what features and lets start the discussion about how to integrate them. In the other hand if you want to build a PEAR DB like class that internally uses Metabase I could help giving ideas if you find it necesary. Tomas V.V.Cox