Re: Merging PHPLIB into PEAR

> I don't think that this is necessarily a good idea. An application framework > dictates a specific philosophy of application design on the people writing > applications. Things like permissions and authentication, no matter how > generically written, dictate some model of permissions, some model of > authentication - and users - to people that simply is not going to work for > everyone. Binarycloud is an application framework. Horde is at least part of ah, fantastic. thanks for speaking the truth, chuck :) ok, I just posted a big rant to phplib's list, I'll summarize here: -binarycloud is going to have public cvs up in 10 days. -we will build some infrastructure for binarycloud.com _using_ binarycloud, including a bug module, a file registry, a module/application registry, and a developer registry. we'll use the existing binarycloud knowledgebase module, and probably port a forums package, as well. (and anything else anyone can think of) think of is this way: -PEAR will be the library repository -binarycloud core will be the application framework -binarycloud.com will primarily be an application repository. the idea behind binarycloud is to be able to plug in application, turn them on, and have them work. that allows you to build your own applications without having to put in tons of time setting up a system which properly handles basic tasks for you. my only real worry is the choice of db abstraction layer, and "PEAR" error handling. I've already got productino quality packages that perform both of theose functions. one is metabase, the other is the binarycloud error handling infrastructure. I'm happy to donate the latter. The former (metabase) is free, I see no reason not to use it. How mature and production tested is the PHPLIB db abstraction layer? > application framework. Horde builds on _top_ of PEAR, but I'm not going to go > committing the Horde preferences code to PEAR - it's one way of doing it, but > it's such a variable thing that it probably wouldn't make sense for people who > weren't interested in more of Horde. However, I _have_ contributed the Log > classes, HTTP_Compress, and other classes that we wrote that solve simple, > smaller problems that people can build on. Even the Log classes are debatable, > btw. > > I'm not sure if I'm articulating my ideas very well, and I don't know if > anyone > else agress with me. But I'm curious either way. =) and the kicker: -so long as PEAR _does_not_ dictate any system design, but instead only enforces code and documentation standards - binarycloud and PEAR will happily co-exist. from the conversations I have had with stig, I don't _believe_ that will be an issue, but now is definitely the time to clear all of that up. best, _alex -- Alex Black, Head Monkey enigma@turingstudio.com The Turing Studio, Inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 Saul Zaentz Film Center 2600 Tenth St Suite 433 Berkeley, CA 94710-2522