RE: [PEAR-DEV] general questions

> 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. Yes this is exactly what I wanted to say. Lets do it right and only provide wrappers for legacy support. To the ADODB folks: I have not done benchmarks myself but if ADODB is such a speedster then please help us incorporate this into this new abstraction layer. Also as Manuel pointed out Metabase is OO .. so porting is not that insanely difficult todo. Like I said we had some thing along the lines of the get*() PEAR DB functions in metabase in no time at all. Also Manuels code is not crap! And I do not see any point in redoing all of his work. If you want that then there is nobody stopping you from writing all of Manuels features into Pear DB and then there is no need for a "merge". So I must say my starting point will not be PEAR! I have no problem with the PEAR the function names that PEAR uses .. so I do not see a reason why not to use the same functions for the final version using those names (and therefore not requiring a wrapper to make use of those names). I will not port some of the stuff that is part of the PEAR DB fetch*() stuff. Those features basically allow a programmer to write bad SQL queries and then do the real sorting/searching inside of PHP. But anyone else is obviously welcome to do this. I would violently oppose those functions becoming part of the work component though. We should create a nice way to load this added functionality when need. Same with some of the create/alter related functions that metabase offers. Same with the encryption stuff that binarycloud did. Same with stuff like working with Syntax difference between RDBMS for SQL functions (SUBSTR() - SUBSRTING()). Etc etc To the idea of further abstracting things (LDAP, OODBMS, Files etc) Yes I see some merit in this (I wanted to work on something like that for LDAP as I have stated earlier). But remember that there are not just differences between how to the data is stored in these different DB's but also how they are retrieved. Reducing this all to one API will in effect probably eliminate the different advantages of these DB's. It would be cool to be able to do it though :-) 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 _______________________________ > -----Original Message----- > From: cox@idecnet.com [mailto:cox@idecnet.com] > Sent: Thursday, November 29, 2001 7:01 PM > To: Joao Prado Maia > Cc: Lukas Smith; pear-dev@lists.php.net > Subject: Re: [PEAR-DEV] 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 ? > > > > 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 > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, e-mail: pear-dev-unsubscribe@lists.php.net > For additional commands, e-mail: pear-dev-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net