RE: [PEAR-DEV] general questions

> >To those other reply's to my questions: it really does not make sense > >giving me answers like that ('consitency' etc.)... > > First you asked a question and now you complain because you got > answers? ;-). Indeed .. answers themselves are of no use .. it’s the content that matters Anyways I am getting there in terms of understanding with the help of this list. :-) > >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. 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. And some day it all might be turned into a C Extension :-). But the important thing is that after the merge there is more than one DB abstraction layer with 2 legacy wrappers but that there is actually a core component that is the best of both worlds and then some. Also obviously Manuel suggested that I could do this because he is really deep into Metal (btw: Metal will be able to do some amazing things for a Db abstraction layer). Since I wanted to redesign parts of metabase anyways and I am also in the process of looking what features I am missing from metabase, it seemed to make sense to me to also get this thing under the Pear umbrella. Also I will have to look at ADODB .. since everybody is saying how fast it is :-) (anyone know why?) I will be doing this with Christopher Linn, a co-founder of my company. We do have a testing linux server available, where we can do nuts and install all sorts of RDBMS but obviously the point of all this is to have this work as a community effort (and I really don't feel like writing drivers for all those RDBMS out there). 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. Best regards, Lukas Smith smith@dybnet.de _______________________________ DybNet Internet Solutions GbR Alt Moabit 89 10559 Berlin Tel. : +49 30 83 22 50 00 Fax : +49 30 83 22 50 07 www.dybnet.de info@dybnet.de _______________________________