pearifying metabase: phase 1

Hi All, Just trying to get a list together here; any comments greatly appreciated: Structural differences (or better what will need to be added to metabase to include or be compatible with pear db's features): You will find my naming of the "todos" to be a bit optimistic (resolved, minor, small, large, unsure) but that is just a way to categorize the different things This list might see some expansion in the future. Under resolved I will list anything that will soon we included in Metbase, has just been included or has been included for some time .. or more exact: anything we don't need to worry about. The other categories should be self explanatory. If needed we can always add another category: "extra large" :-) So here it goes: Resolved: - Missing Drivers Sybase (resolved: is coming) - get* family (resolved: with the latest release) - placeholder function (resolved: metabase actually has had this for quite some time) Minor: - fetchmode (minor) - DSN support (minor) - Missing Drivers Frontbase (minor?: will the frontbase guys write one/modify the current for us?), LDAP (minor: I want it myself, but the driver is fairly new and not that "feature rich" yet, so we should be able to port it) - tableInfo (minor: metabase allready has some of those features) - flexible default behavior (minor: shouldn't be too big of a deal to implement) Small: - Error support (small?: maybe not a big deal through the use if customer error handler feature of metabase) - transaction (small?: I haven't look at either metabases' nor pear db's implementation) - DB_result object (minor) - error messages (small?) - getListOf (small?: Thomas was not sure about the status inside of PEAR of these features) Large: - LOB support (large?: I haven't look at either metabases' nor pear db's implementation) - API changess like function naming, parameter orders, coding style stuff (large: a lot of work but nothing too complicated) Unsure: - storage.php (?: is this used a lot? Will this work out of the box once we get API compatibility with PEAR DB? This could basically be understood as another level of abstraction . maybe this is where the LDAP handler should actually "attack" rather than as it is now in the level of PEAR DB core that was meant for relational rdbms) - different ways of how data is stored in the DB for emulated features: sequences, NULL ..? (?: this is actually one of those most difficult areas .. hopefully a simply convert script could take care of it . but its definitely ugly if certain features have been emulated differently in the db) Approach: Dunno if this is crazy, but I would much rather not start off building wrappers, but to actually work on a merged version that is easy to make backward compatible with both abstraction layers (again as a warning this is my first shot at merging two fairly large and estabhlished projects - especially with opensource you gotta please the public or you will face forks with would defeat the purpose of this merger - so I am a bit nervous). Probably I will attempt at getting Pears DB.php to play nice with the metabase_database.php :-) Best regards, Lukas Smith smith@dybnet.de PS: For anyone hoping for a faster pace with this development: unfortunately I do have very limited time to work on this. So any help is greatly appreciated. _______________________________ DybNet Internet Solutions GbR Alt Moabit 89 10559 Berlin Germany Tel. : +49 30 83 22 50 00 Fax : +49 30 83 22 50 07 www.dybnet.de info@dybnet.de _______________________________