Re: PEAR DB abstraction layers
| From: | Lukas Smith | Date: | Mon, 19 Apr 2004 13:44:49 +0000 |
| Subject: | Re: PEAR DB abstraction layers | ||
| References: | 1 2 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-28023@lists.php.net to get a copy of this message | ||
Paul M Jones wrote:
Hi, all,I think its obvious that DB has a more prominent position, even just because its listed under the more obvious name of DB. Since we plan to unbundle all none installer required packages from PHP5 the fact that DB is bundled and MDB is not will not confuse users into some hirarchy in the future.But the question really is what is our recommended DBAL? I think its time that MDBx is moved to the status of the recommended DBAL in PEAR.I wasn't aware that PEAR "recommended" *anything.* I thought, perhaps incorrectly, that PEAR was a loose collection of classes from which one might choose at will, and that the only recommendation was to use what worked for you.
If DB, for all its flaws, works well for developer A, then DB is for him; if MDB2 works well for developer B, then MDB2 is for him. One might just as well say "HTML_Template_Xipe" is the "recommended" template, or HTML_Form is the "recommended" form builder. The packages are there for all to see and choose from, each according to the user's needs and requirements.MDB[2] and DB are redundant packages as they dont follow any fundamentally different approach. Its just that MDB2 builds on DB and Metabase to provide a package that is superior in performance and flexibility over DB. Therefore we should deprecate DB imho in favor of DB_va aka MDB2.
Marketing and awareness on a per-package basis may be an issue, but I think that work should be reserved for the individual developers or package teams; we should not allow developers to use the shortcut of a "recommendation" declared by fiat. If a package serves an active need, has good documentation, useful examples, is easy to get started with and use regularly, etc., then there will be a natural acceptance rate (or lack of acceptance) depending on how well it suits the *actual* needs of users (vice the needs *perceived* by the package developer). That rate may or may not match the patience of the package developer.Well as I explained above it is not about saying that one technically differnt package is better than another, but that one package is simply superior to another package which makes the previous one redundant. The only thing that you can say makes DB better than MDB2 is a few parameters that you currently have to pass as "null" if you dont care for this feature. Also it was the original plan from the very beginning to make MDB the next major version of DB.
This is the point of competition among packages: if a developer perceives a need, but users do not accept it or choose something else, that developer's estimate of the need may have been inaccurate. The answer is not to have PEAR Group (or whoever) declare "out with the old; in with the new (mine!)" (which can take many forms, from an explicit "you should not use the old" to "the old is fine but we officially recommend the new", essentially a political statement). Instead, the developer should refine his connection with actual user needs (not perceived needs) or increase marketing and awareness efforts. Whoever does the best job there will see the most use of their work.We dont have competing packages in PEAR. We have different packages in PEAR which might address the same tasks but which follow a fundamentally different approach. MDB[2] just exists because it was decided to be too difficult and lengthy a process that we could immediatly call it DB_v2.
(I have more to say about this, but it will have to wait, as I have appointments for the next few hours. I'll see how this thread progresses and write my rants later in the day. ;-)So to conclude I am asking to follow up on the original plan of making MDB the next major version of DB. Aside from that MDB2 is superior in everyway to DB (I am saying this not to diss the DB developers ... MDB2 is afterall build based on the experiences and the code from the DB package). If there are API decisions to make then these are a separate solveable issue. regards, Lukas Smith smith@backendmedia.com _______________________________ BackendMedia www.backendmedia.com berlin@backendmedia.com Linn Zwoch Smith GbR Pariser Str. 44 D-10707 Berlin Tel +49 30 83 22 50 00 Fax +49 30 83 22 50 07