Re: [binarycloud-dev] FW: lets talk "metapear" - politics aside :-)

> Since I seem to have forgotten to send my release announcements to this > mailinglist ... > > So all code can be found at www.dybnet.de/metapear Cool, in CVS on Monday. All (be people): I'm going to put up a testing RFC for this stuff... anyone interested in taking it? > This is just a proof of concept and is basically metabase with a bunch of > pear related additions in terms of methods and a bit of pear error handling Cool. > There can still be a lot of code safed I think (especially with the get*() > family of methods that are basically only slightly modified from the > original pear code) There is as always much to do :) continues... >> 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. I have no such qualms about standing in public :) Your efforts are timely and necessary. You will receive support from the binarycloud camp, as we stand to benefit greatly from your efforts. Eventually you may even find that some people that were doing core dev on binarycloud are interested in helping with metapear. >> 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". As do I. I think this is the best of both worlds. Also dynamic loading of components is important, as Metabase currently loads everything, which is unnecessary. It still rocks, but there is obviously a lot to do. The most important work that manual did with that code is real, _true_ field/datatype level abstraction across multiple DMBSs - in that sense it is a true abstraction layer. Everything else about metabase, i.e. the API, loading, etc I think can be either toasted and done over or tweaked until it's faster. I don't think metabase will ever be as fast as ADODB (hock, spit), or PEAR:DB, because it does so much more. At the same time I think there is quite a lot of stuff that could be done to make it a lot faster. >> slow but that is because no effort was made to make it fast. This should Well said. >> 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. This is important and I'm glad you know about it / want to fix it. >> 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". What do you mean by 2 wrappers? do you mean DBMS wrappers? Oh nevermind I kept reading, I get it. A BC metabase wrapper and a BC PEARDB wrapper? >> 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 I have never used that nor do I particularly like the idea :) >> need while they are allready working through the result set. So I would want >> to throw those out as well. Yep. >> 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 I agree - as long as you don't chuck anything that metabase was able to do before. Actually, on that subject I think the XML-schema-parsing/loading stuff could be a separate package. That is the other _fantastically_ cool thing about metabase (the XML schema stuff) which should stay. I think a separate package makes sense though. >> making the API nice and compact. I might be going too far though in my >> suggestions. So again I am looking for comments. Not so far. Everything you're saying synchs right up nicely with what I and others have wanted for some time. >> 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. This is an area where I really am tempted to say screw BC. :) Requiring PEAR.php isn't that big of a deal, and I would _love_ to get proper PEAR error objects from the abstraction layer, as that is the error standard (PEAR's) that we use in binarycloud, with some extra metadata that we like shoved in user_info :) I think you might even want to abstract the error call interface a bit so you can "detect" pear and use that error stuff or just use PHP's throw_error or whatever that function is called. >> 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 That is a key ++good thing about PEAR_DB. I want error messages with codes so we can act on those codes in our own code and propagate meaningful actions and messages up the render pipeline. Very important to include codes, exactly the way PEAR does it now, which works very well. >> 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. I'm interested in manuel's opinion on this. I think the way above would be fine. >> 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. Lukas, so far your decisions have been 100% sound. So while I agree with you about code review, at the same time I now completely trust your judgement. So we'll give you feedback but don't let us hinder your progress. Do what you think is right, check in once and a while, and if you happen to miss something we'll fix it - a lot of people will use this :) _a