Considering package proposal: Cgiapp

I have been maintaining a package for a little over a year, and use it regularly in my PHP development. The package is a PHP port of a perl module, CGI::Application. I originally considered proposing it to PEAR, but at the time, my feeling was that it didn't fit well with PEAR. Due to some recent discussion on the pear-dev list, however, I think it may fit well now. Discussion regarding MDB_QueryTool and PEAR_Frontend_GTK, among others, makes me think so; I've read comments about how applications specific to PEAR functionality or completely abstract application building tools fit best into PEAR's mission. Cgiapp fits into this latter category. Basically, Cgiapp (http://cgiapp.sourceforge.net/) is a class for creating web applications. By itself, it is *not* a web application -- it needs to be extended to do anything. The basic tenet of the class is that applications are built of run modes, and each run mode is represented by a single method within the class. As an example, a basic application may consist of a splash page with a search form, search results, and an individual result; these would be the three run modes for that application ('form', 'results', and 'item', for example). The class' usefulness is primarily in providing a solid framework for building reusable web applications. As an example, where I work we have created a Cgiapp-derived superclass that handles authentication, placement of content in a sitewide template, configuration of sitewide content on a per-application level, etc.; all applications then derive from this superclass, which gives them a common framework. Applications can also be easily extended; as an example, I extended a basic image gallery class to create an ecards class. Because each application is an extension of the class, and of Cgiapp, it also means that for a new developer to dive into the class for maintenance or feature additions, the structure is immediately familiar. I have built Cgiapp as a fairly strict port of the perl module. My roadmap for it is built around known developments on that same source. While I am open to some suggestion regarding its direction, I am leaning towards keeping it lean and mean, and as close to the perl module's API as possible (to allow porting of applications between the two languages). I've got phpDoc documentation for the class at: http://cgiapp.sourceforge.net/cgiapp_doc/ A .phps of the class is available at: http://cgiapp.sourceforge.net/cgiapp_doc/Cgiapp.class.phps I've had some difficulty determining where in the PEAR repository a class like Cgiapp would belong. My though is "Tools and Utilities", but I'm open to suggestion. What I'm wondering is, should I bother proposing the class? Does it fit with PEAR's mission? Are there any changes you, as pear-dev's, think I should make to the class before an official proposal? -- Matthew Weier O'Phinney mweierophinney@gmail.com http://weierophinney.net/matthew/