lets talk "metapear" - politics aside :-)

Aloha, I know this will turn into yet another difficult thread (if people even start answering :-) ). All I can say right now is that I have been emailed in private by both sides (someone from PEAR DB and Metabase) which is all fine if people want to keep it that way but which will obviously limit some of the collaborative advantage that opensource development normally provides. Anyways as I have stated previously what I (and I assume everybody else involved as well) want to have is the best features, API and performance optimizations of both PEAR DB and Metabase in what I am now calling "metapear". In terms of performance it will probably be slightly slower than PEAR DB has been because of the longer parsing time required because of the simple fact that there are more methods. Right now the performance of "metapear" is fairly slow but that is because no effort was made to make it fast. This should change now. Also keep in mind that 1) parsing time is quite insiqnificant compared to the time it takes queries to be executed and 2) using a script caching engine can do away with a lot of that overhead. Finally the current Metabase (and therefore "metapear") always loads a lot of seldom used functionality which will be moved to separate packages. In the end I want to have 2 wrappers and one core component. Metabase always has had a wrapper in the form of mysql_interface.php. PEAR DB will also need to get a wrapper most likely in order to keep BC with the old PEAR DB but not bloat "metapear". Keep in mind that I am just talking about the core of "metapear" here ... everything will be totally BC through wrappers. I have added QuerySetArray to Metabase to be able to set all placeholders with a prepared query with one call. The difference with the get*() family of methods is that this can also make use of Metabases convert functions. But since get*() calls QuerySetArray this is allready available (allthough untested atm). Can we send throw out QuerySet[Null|Text|...]? It seems to me that something along the along the lines of the get*() or MetabaseQuery[Field|Row|Column|All] are the way to go. Honestly I am not sure though if running a normal query and running a prepare execute really need to be stuck in one function. I really don't like having a bunch of optional parameters that can even all be of various types which get*() relies on. So in this case I lean towards the Metabase way in this case. Something similar to get*() can be achieved with a combination of QuerySetArray and prepare()-execute()-executeMultiple(). This basically just leaves something like getAssoc() missing, which I honestly never missed myself but I can see being useful. Another question: Does "metapear" even need to be able to retrieve resultsets step by step? I really do not see the advantage there. People should ensure that they only get the data they care about and not decided how much data they need while they are allready working through the result set. So I would want to throw those out as well. The basic idea here is to really reduce "metapear" to the absolute minimum of methods. I think this is an important part of speeding "metapear" up and also making the API nice and compact. I might be going too far though in my suggestions. So again I am looking for comments. The thing that now has to be decided is what methods should be in "metapear" and what methods should be moved to each of the wrappers. The other important issue is error handling/abstraction: In all of the discussion I think one of the main issues was that Metabase requires 100% portability while PEAR DB is mainly about a cross DB API and to a lesser degree about portability. But portability is exactly what PEAR DB stands to gain along with a lot of other stuff. So I would like to hear concepts about how "metapear" should do this while keeping BC in mind. From what I have gathered Metabase will be a bit easier for BC in that respect since Metabase focuses on getting the developer information to manually debug while PEAR DB tries to abstract error codes in order to allow code to act based on those. I currently have not ha time enough to really think of a good solution that will please all parties and I would really like to hear a proposal as to how best do this. All of this are important steps in streamlining "metapear" so it is really important to get some level of agreement on all of this. This will require that people look at the actual code that is now in place within "metapear" because I don't think that it makes sense for me to make these decisions alone. I hope people will find the time and that people now have enough faith in this merger that they feel that investing time will not turn out to be a waste of time. Best regards, Lukas Smith smith@dybnet.de _______________________________ 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 _______________________________