RE: [PEAR-DEV] general questions

On Thu, 29 Nov 2001, Lukas Smith wrote: > > >To the question of keeping two Db abstraction layers or only one: Yes > I > > >think it makes sense keeping only one abstraction layer. And since > the > > >API will have to change for metabase (and this is one of its main > > >weaknesses) obviously metabase also has a userbase to think off. > > > > Please keep backwards compatibility. PEAR DB is already used by > > a lot of people in production areas. Breaking BC will be the worst > > thing we can do. > > > > Adding new features is OK, but we can't break to much (this does > > not only apply to BC, but also to performance issues). > > 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 ? 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. > 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. 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. 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