Re: PEAR_Server

Alan Knowles wrote:

I would definatly favour getting it into PEAR, but it's really a greg's decision. Maintaining a PEAR package can be quite time consuming, and developing outside of PEAR does free you up from some of the commitments. (i can attest from my akpear repo.)

"Chiara_PEAR_Server will be phasing out use of DB_DataObject in favor of Davey Shafik's Crtx_DB_DataObject, a data access class that uses PDO and is E_STRICT PHP5" I don't believe that this is really necessary. But if it really is, what about moving Crtx_DB_DataObject to DB_DataObjects2?

I had a quick look at this, at present, The core class only has a tertiary similarity to DataObjects, and misses alot of the lessons learned from DataObjects (It's adds alot of low use utility methods to the core class, and misses some of the key goals). DBDO is nearing it's alpha release, and would be a better target for API compatibility If anyone wants to attempt a DataObjects2 specifically for PHP5/PDO.

I was hoping that channels might elevate the status of external repositories a bit, i.e. if users think code is good, then they have an easy way to install it. If you built it (well), they will come kind of thing. This is an old-fashioned way of thinking, perhaps :) As for the question of what to use as a data backend, I used DB_DataObject because it is robust, easy to use, and has a large userbase. However, I designed PEAR_Server/Chiara_PEAR_Server so that it can easily plug in a different Dataobject backend or anything at all. The PEAR_Server_Backend base class is an abstract class, and you have to implement all the abstract methods, so it's pretty easy to tell if you forgot one since PHP5 gives a fatal error. If someone takes it upon themselves to write a backend for whatever is out there, I'll provide a way to install it, so users can choose what they want to use based on their setup. However, before we go any further on the road of PEAR_Server being in PEAR, we MUST resolve a fundamental question: I think cross-channel dependencies are great, but PEAR should not have them in its packages unless there is a REALLY good reason. I don't see one yet for PEAR_Server/Chiara_PEAR_Server. Also, to be perfectly honest, I don't want to deal with the politics that surrounds adding a package to PEAR unless there won't be any :). I have enough to deal with PEAR_ErrorStack thank you very much. Greg